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1.  INTRODUCTION 


As  formal  specification  technology  continues  to  develop,  the  constructs  available  in  specification 
languages  will  differ  increasingly  from  those  available  in  the  various  implementation  languages.  A 
problem  then  arises  in  the  mapping  between  these  disparate  language  levels.  Implementation 
languages  simply  do  not  possess  the  ability  to  directly  express  concepts  found  in  specifications  This 
is  as  it  should  be.  because  the  languages  are  designed  for  different  purposes:  implementation 
languages  are  for  describing  efficient  algorithms,  and  specification  languages  are  for  describing 
behaviors. 

One  goal  in  the  design  of  formal  specification  languages  is  to  ease  the  task  of  writing 
specifications.  One  approach  is  to  use  a  specification  language  that  reduces  the  burden  in  two  ways 
First,  by  enhancing  expressiveness,  this  type  of  language  allows  the  specifier  to  state  his  desires 
more  easily.  Second,  by  requiring  only  a  description  of  intended  behavior  rather  than  the  detailed 
specification  of  a  particular  algorithm,  this  language  affords  a  specifier  the  freedom  to  specify  what  is 
desired  rather  than  how  to  achieve  it. 

This  approach,  however,  aggravates  the  problem  of  producing  a  correct  implementation  from  the 
design  specification.  In  this  paper,  we  investigate  a  solution  to  this  problem  by  presenting  a  number 
of  implementation  options  for  each  of  several  high-level  specification  constructs.  We  then 
demonstrate  that  the  mappings  of  these  high-level  specification  constructs  into  implementations  are 
derivable  by  sequential  application  of  relatively  straightforward  correctnesspreserving1 
transformations.  The  collection  of  high-level  specification  mappings  can  be  viewed  as  the  major 
conceptual  steps  in  a  "transformational  implementation." 

The  work  presented  here  should  be  viewed  as  being  but  part  of  a  larger  effort  (being  conducted  by 
the  Transformational  Implementation  (Tl)  group  at  ISI)  investigating  reliable  software  development  by 
considering  methods  for  automating  aspects  of  the  software  development  process.  The  methodology 
we  have  adopted  for  developing  reliable  software  comprises  the  following  activities: 

1.  system  specification  in  a  formal  language  designed  for  specification; 

2.  elimination  of  high-level  specification  constructs  by  mechanical  application  of 
correctness- preserving  transformations; 

3.  selection  and  development  of  algorithms  and  abstract  data  types  to  effect  behavior 
described  in  the  specification  (also  by  mechanical  application  of  correctness-preserving 
transformations);  and 

4.  translation  into  the  target  implementation  language. 

The  implementor  maps  the  specification  into  an  implementation  through  the  selection  and 
application  of  appropriate  transformations  (from  a  pre-existing  catalog).  The  programmer  in  this 
scenario  has  control  over  the  implementation  process,  making  many  of  the  same  decisions  he  would 
ordinarily  make.  Our  goal  is  to  construct  a  system  which  will  relieve  some  of  the  implementor's 
burden  by  performing  the  perfunctory  tasks  of  bookkeeping  and  program  source  text  maintenance. 
Specifically,  the  following  portions  of  this  software  development  system  will  be  automated; 


1  Since  in  our  view  a  specification  denotes  a  set  ot  behaviors,  our  notion  of  a  'correct”  transformation  is  one  whose 
application  results  in  a  specification  denoting  a  subset  of  those  behaviors  (a  nonempty  subset,  provided  that  the  original 
specification  denoted  a  nonempty  set  of  behaviors) 
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1.  toolss  to  assist  the  implementor  in  deciding  on  the  appropriateness  and  applicability  of  a 
given  transformation, 

2.  a  mechanism  for  applying  a  chosen  transformation  to  the  developing  program, 

3.  support  for  the  development  process  (e  g.,  automatic  production  of  documentation  and 
"replay"  facilities  which  allow  a  development  to  be  repeated  so  as  to  reimplement  a 
modified  specification). 

4.  the  catalog  of  correctness-preserving  source-to-source  transformations,  which  embodies 
the  Knowledge  of  alternative  implementations  of  particular  specificational  constructs,  and 

5.  a  mechanism  for  translating  a  fully  developed  program  into  a  target  implementation 
language. 

The  specification  language  itself  is  critical  within  this  software  development  framework.  Two  basic 
characteristics  are  required  of  the  specification  language.  The  first  of  these  is  that  the  language 
provide  the  flexibility  and  ease  of  expression  required  for  describing  the  full  range  of  acceptable 
behaviors  of  the  system  under  design.  See  [2]  for  a  description  of  the  requirements  for  specification 
languages  that  will  exhibit  these  characteristics.  The  second  requirement  of  a  specification  language 
for  our  software  development  methodology  is  that  it  be  wide-spectrum  [7],  This  means,  in  essence, 
that  the  same  language  can  serve  both  as  a  specification  language  (for  describing  the  full  range  of 
acceptable  behaviors)  and  as  an  implementation  language  (for  describing  an  efficient  program  whose 
behavior  is  true  to  the  specification).  In  reality,  the  specification  language  need  be  wide-spectrum 
only  up  to  a  point;  after  selection  of  algorithms  and  abstract  data  types,  the  "implementation"  can 
automatically  be  translated  into  a  suitable  implementation  language. 

Our  group  has  developed  such  a  language,  called  Gist  [25],  which  permits  expressibility  by 
providing  many  of  the  constructs  found  in  natural  language  specifications  of  processes.  These 
expressive  capabilities  include  historical  reference  (the  ability  to  refer  to  past  process  states). 
constraints  (restrictions  on  acceptable  system  behavior  in  the  form  of  global  declarations),  a 
relational  and  associative  data  model  which  captures  the  logical  structure  without  imposing  an 
access  regime,  inference  (which  allows  for  global  declarations  describing  relationships  among  data), 
and  demons  (asynchronous  process  responding  to  defined  stimuli),  among  others.  Thus,  the  effort  in 
Gist  has  been  to  provide  the  specificational  expressiveness  of  natural  language  while  imposing  formal 
syntax  and  semantics  2 

This  paper  focuses  on  the  transformations  used  to  eliminate  these  high-level  specification 
constructs.  Such  elimination  is  obviously  necessary,  because  no  target  implementation  language  is 
expected  to  provide  such  facilities.  More  important,  to  the  extent  that  the  specification  language  is 
doing  its  job  of  describing  intended  behavior  (what)  without  prescribing  a  particular  algorithm  (how), 
these  constructs  represent  the  freedoms  offered  by  the  specification  language.  How  such  freedoms 
are  implemented  determines  in  large  part  the  efficiency  of  the  resulting  algorithm.  Furthermore,  as 
such  constructs  are  just  beginning  to  be  incorporated  into  specification  languages,  consideration  of 
alternative  implementations  of  these  constructs  has  received  little  attention.  Absence  of  these 
constructs  has  forced  systems  analysts  and  designers  to  choose  (normally  unconsciously)  one 
implementation  as  a  precondition  to  expressing  a  specification. 


2 

Note  that  Gist  syntax  is  ALGOL-like  and  not  English-like! 
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The  development  of  these  high-level  transformations,  which  we  call  mappings ,  presents  a  rich  set  of 
issues  dealing  with  the  translation  of  specifications  into  implementations.  As  it  is  often  difficult  to 
separate  the  activities  of  mapping  high-level  constructs  and  selecting  and  developing  algorithms  and 
data  types,  the  discussion  of  mapping  transformations  will  also  consider  these  issues. 
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2.  PACKAGE  ROUTER  PROBLEM 


2.1  OUTLINE  OF  PROBLEM 

To  illustrate  our  approach,  we  choose  as  an  example  a  routing  system  for  distributing  packages 
into  destination  bins.  This  problem  was  constructed  by  representatives  of  the  process  control 
industry  to  be  typical  of  their  real-world  applications.  Hommel’s  study  of  various  programming 
methodologies  used  this  problem  as  the  comparative  example  [26]. 

Figure  2-1  illustrates  the  routing  network.  At  the  top,  a  source  station  feeds  packages  one  at  a  time 
into  the  network,  which  is  a  binary  tree  consisting  of  switches  connected  by  pipes.  The  terminal 
nodes  of  the  binary  tree  are  the  destination  bins. 


bin 


Figure  2 •  1 :  Package  router 

When  a  package  arrives  at  the  source  station,  its  intended  destination  (one  of  the  bins)  is 
determined.  The  package  is  then  released  into  the  pipe  leading  from  the  source  station.  For  a 
package  to  reach  its  designated  destination  bin,  the  switches  in  the  network  must  be  set  to  direct  the 
package  through  the  network  and  into  the  correct  bin. 

Packages  move  through  the  network  by  gravity  (working  against  friction),  and  so  steady  movement 
of  packages  cannot  be  guaranteed;  they  may  "bunch  up"  within  the  network  and  thus  make  it 
impossible  to  set  a  switch  properly  between  the  passage  of  two  such  bunched  packages  (a  switch 
cannot  be  set  when  there  is  a  package  or  packages  in  the  switch  for  fear  of  damaging  such 
packages).  If  a  new  package's  destination  differs  from  that  of  the  immediately  preceding  package,  its 
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release  from  the  source  station  is  delayed  a  (precalculated)  fixed  length  of  time  (to  reduce  the  chance 
of  bunching).  In  spite  of  such  precautions,  packages  may  still  bunch  up  and  become  misrouted. 
ending  up  in  the  wrong  bin;  the  package  router  is  tc  signal  such  an  event. 

Only  a  limited  amount  of  information  is  available  to  the  package  router  to  effect  its  desired 
behavior.  At  the  time  of  arrival  at  the  source  station,  but  not  thereafter,  the  destination  of  a  package 
may  be  determined.  The  only  means  of  determining  the  locations  of  packages  within  the  network  is  a 
group  of  sensors  (placed  on  the  entries  and  exits  of  switches  and  on  the  entries  of  bins):  these 
sensors  detect  the  passage  of  packages  but  are  unable  to  determine  their  identity.  (The  sensors  are 
able  to  recognize  the  passage  of  individual  packages,  regardless  of  bunching). 


2.2  GIST  USED  TO  SPECIFY  PROBLEM 


The  specification  task  is  to  denote  how  the  portion  to  be  implemented  (switches,  source  station) 
behaves.  To  accomplish  this,  the  specification  models  not  only  this  portion,  but  also  the  surrounding 
environment,  to  form  a  closed  system.  The  environment  is  modeled  in  only  as  much  detail  as  is 
necessary  to  express  the  properties  needed  by  the  system  to  be  implemented  (e.g.,  the  rate  of 
movement  of  packages  through  the  router  is  unpredictable;  however,  packages  never  start  moving 
backwards  through  the  network,  and  packages  never  overtake  one  another).  Within  this  closed 
system,  the  portions  to  be  implemented  are  the  controlling  mechanism  for  the  switches  within  the 
network  and  the  source  station  releasing  successive  packages  into  the  network. 

In  specifying  the  system,  we  aim  to  make  a  clear  and  correct  statement  of  the  behavior  the  switches 
and  source  station  must  exhibit  in  their  interaction  with  each  other  and  the  environment.  However, 
the  specification  strives  to  describe  the  behavior  directly,  without  resorting  to  an  algorithm  that 
effects  that  behavior;  deriving  such  an  algorithm  is  rightly  part  of  the  separate  task  of  implementing 
the  specification.  Therefore,  the  emphasis  in  specification  is  on  what  rather  than  how.  This  emphasis 
is  important  for  making  a  clear  distinction  between  specification  and  implementation;  by  describing 
what,  we  do  not  restrict  the  implementation  freedoms  available.  Section  3  describes  some  of  Gist's 
constructs  that  permit  an  easy  statement  of  "what."  The  entire  package  router  specification  is 
presented  in  Appendix  I. 

In  a  further  effort  to  simplify  the  specification  of  intended  behavior,  Gist  specifications  assume 
p<  _ct  knowledge.  That  is,  any  information  used  to  describe  the  behavior  of  a  system  is  available  to 
each  component  part,  to  describe  its  interactions  with  other  parts.  This  assumption  is  often  not 
satisfied  in  the  actual  system.  In  the  package  router  example,  the  specification  relies  upon  knowing 
the  location  and  destination  of  each  package.  However,  in  the  actual  system  the  destination  of  a 
package  is  only  accessible  while  it  is  at  the  source,  and  its  location  is  only  deducible  from  sensor  data 
indicating  the  passage  of  packages  through  the  network.  In  an  implementation  the  unavailable 
information  must  be  deduced  from  other,  available  information.  This  problem  would  complicate  the 
description  of  the  system  behavior  by  substituting  a  how  for  a  what  description.  For  this  reason,  we 
have  therefore  separated  these  two  issues.  The  specification  is  based  on  the  perfect  knowledge 
assumption  and  the  actual  implementation  is  described  separately,  as  are  all  other  implementation 
issues. 


3.  MAPPINGS 


In  this  section  we  will  consider  in  turn  several  high-level  Gist  constructs  and  show  the  following  for 

each: 

1. why  it  is  a  useful  specification  construct,  illustrated  by  presenting  a  use  of  it  in  the 
package  router  problem. 

2.  what  implementation  alternatives  exist,  achieved  by  mapping  the  construct  awa>.  and 
what  the  implications  are  of  those  alternatives. 

In  Section  4  we  will  demonstrate  how  these  mappings  can  be  derived. 


3.1  HISTORICAL  REFERENCE 

Historical  reference  refers  to  the  ability  to  extract  information  from  any  preceding  state  in  the 
computation  history.  The  ability  to  do  this  frees  the  specification  from  determining  in  advance  (and 
remembering)  all  current  information  that  might  be  required  at  some  time  in  the  future  Required 
information  is  merely  retrieved  at  the  point  of  consumption  without  concern  for  when  it  is  available 


3.1.1  Example  From  Package  Router 

The  source  station  is  to  control  the  release  of  packages  into  the  network  as  follows.  If  a  newly 
arrived  package's  destination  differs  from  that  of  the  immediately  preceding  package,  delay  release  of 
the  new  arrival,  otherwise  release  it  at  once.  The  "historical  reference"  here  is  to  the  destination  of 
the  immediately  preceding  package.  Using  Gist  this  portion  of  the  specification  is  expressed  as 
follows. 

demon  RELEASE  PACKAGE  INTO  NETWORK[packaoe.new) 
trigger  package. new  :  At  =  the  source 

nssaaosa 

begin 

jf  package. new  :  Destination  * 

(g package-previous  || 

package. previous  immediately  <  package. new 

Ml  PACK AGES_EVER_AT_SOURCE(*) ) :  Destination 

then  WAIT[] : 

update  :  At  gf  package. new  Jn  (the  source) :  Source_Outlet 
end; 

relation  PACKAGES_EVER_AT_SOURCE(pac*age$  I  sequence  of  package) 
definition  packages  =  ( g  package  )  ordered  wrt  package  :  At  =  ( IhS  source  ) ; 
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In  English, 

Determination  of  when  to  release  a  package  into  the  network  commences  when  a  new 
package  becomes  located  at  the  source  station. 

H  the  new  packace's  destination  differs  from  that  of  the  previous  package  (that  is.  the 
package  immediately  preceding  the  new  package  in  the  sequence  of  packages  to  nave 
been  located  at  the  source  ( defined  below)),  men  wait. 

The  sequence  of  pack  ages  ever  located  at  me  source  /s  defined  b,  nondetermimsticahy 
refe’r.ng  to  packages,  and  ordering  mem  by  the  order  in  wh:cn  they  were  located  at  the 
source-  aer  ven  relation"  PACK  AGES_EVER_AT_SOURCE 

Historical  reference  proves  to  be  of  significant  utility  here  because  it  frees  the  specifier  of  concerns 
about  how  to  save  information  that  is  required  but  not  readily  available  in  the  current  computation 
state. 


3.1.2  Mapping  A«a\  Historical  References 

Options  for  mapping  historical  references  away  are  as  follows. 

•  Introducing  and  maintaining  auxiliary  data  structures  to  hold  information  whicr  might  be 
referenced,  and  modifying  the  historical  references  to  exhac:  the  information  front  these 
introduced  structures.  The  requirement  for  econom>  o'  storage  m  ar.  implementation 
encourages  the  implementor  to  seek  a  compact  representation  for  the  information  that 
need  be  preserved  and  to  discard  information  once  it  is  no  longer  useful 

•  Resolving  the  historical  reference  by  derivation  in  terms  of  information  ava  iable  in  the 
current  state  (without  having  to  retain  extra  information  from  past  states; 

We  suspect  that  the  latter  is  rarely  an  available  option  When  it  is.  the  twe  alternatives  above  present 
the  classical  space/time  tradeoffs:  we  must  still  compare  the  cost  of  the  derivation  with  the  cost  of 
storage  and  maintenance  of  redundant  information  to  permit  simple  access  In  the  case  of  our 
example,  the  specification  indicates  no  way  to  derive  the  identity  of  the  previous  package  passing 
through  the  source  station.  Thus  the  first  option,  that  of  introducing  auxiliary  data  structures,  must  be 
used  in  this  case. 

Two  factors  bear  directly  on  the  range  of  choice  of  how  much,  and  what,  information  needs  to  be 
retained  in  an  implementation  of  historical  reference  These  are  the  nature  of  the  retrievals  of  the 
information  and  how  it  is  used.  Both  these  factors  are  evident  in  our  chosen  example 

First,  through  examination  of  the  entire  specification  we  see  that  the  only  occasion  in  which  this 
particular  historical  reference  is  made  is  when  a  new  package  has  entered  the  source  station. 
Further,  we  refer  only  to  the  package  immediately  preceding  the  very  latest  package-  earlier  ones  are 
no  longer  of  any  interest.  Hence  an  implementation  need  remember  only  the  most  recent  package  to 
have  passed  through  the  source  station  rather  than  all  of  them. 

Second,  we  see  that  the  only  information  we  require  from  the  historically  referenced  prev  ous 
package  is  its  destination  (in  order  to  compare  it  with  the  destination  of  the  new  package).  Since 


o 

''Another  Gist  construct  see  Section  3.3 
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destinations  are  static  attributes  of  packages  (a  property  easily  provable  of  the  specification),  we 
could  choose  to  remember  only  the  preceding  package's  destination  as  opposed  to  its  identity.  In 
general  we  must  compare  the  frequency  of  storing  the  information  with  the  frequency  of  accessing  it 
to  determine  whether  it  is  better  to  perform  the  calculation  upon  storage  or  upon  retrieval.  In  our 
simple  example  we  can  see  that  there  will  be  more  retrievals  than  stores  (because  it  is  necessary  to 
store  the  destination  only  when  it  changes),  so  we  choose  to  retain  the  destination  rather  than  the 
identity.  Thus  our  historical  reference  is  mapped  into  the  following:4 


demon  RELEASE_PACKAGE_INTO_NETWORK[package.new] 
triaoer  package. new  :  At  =  the  source 
response 
begin 

if  package. new  :  Destination  *  PREVIOUS_PACKAGE_DESTINATION(*) 
lhen  WAIT(] : 

update  :  At  gf  package. new  tg  source  :  Source_Outlet; 

update  ppdest  in  PREVIOUS_PACKAGE_DESTINATlON($) 
tg  package. new  :  Destination 

sod- 

relation  PREVIOUS_PACKAGE_DESTINATION(ppcfesr  |  bin)  ; 


3.2  CONSTRAINTS  AND  NONDETERMINISM 


Constraints  within  Gist  provide  a  means  of  stating  integrity  conditions  that  must  always  remain 
satisfied.  Within  Gist,  constraints  are  more  than  merely  redundant  checks  that  the  specification 
always  generates  valid  behaviors:  constraints  serve  to  rule  out  those  behaviors  that  would  be  invalid. 
In  conjunction  with  the  use  of  nondeterminism,  they  serve  as  an  extremely  powerful  specification 
mechanism,  permitting  us  to  describe  an  activity  in  a  nondeterministic  fashion;  those  behaviors  of  the 
activity  leading  to  states  that  violate  the  constraint  are  "pruned  away.”  We  are  thus  able  to  express 
our  intents  more  directly  (in  the  form  of  constraints)  rather  than  encoding  all  the  processes  of  the 
specification  so  as  to  interact  in  only  those  ways  that  prevent  arriving  at  an  undesirable  state. 


3.2.1  Example  From  Package  Router 


always  prohibited  MORE  THAN  ONE  SOURCE 
exists  source.  1 ,  source. 2; 


4Section  4  gives  the  actual  development  steps  lor  reaching  this  state. 


MAPPINGS 


9 


This  constraint  prohibits  the  existence  of  more  than  one  source  by  defining  a  predicate  that  must 
never  be  true.5 

In  the  package  router,  constraints  such  as  MORE_THAN_ONE_SOURCE  define  the  nature  of  the 
world  in  which  the  specified  system  will  exist.  The  constraint  does  not  directly  constrain  the  part  of 
the  specification  to  be  implemented.  Constraints  that  do  affect  the  behaviors  of  the  portion  to  be 
implemented  receive  the  most  attention  in  the  development  of  an  implementation. 


3.2.2  Another  Example  From  Package  Router 


demon  SET_SWITCH{sw/fcb] 
trigger  RandomQ 
response 
begin 

require  SWITCHJS_EMPTY(swifcb); 

update  :  Switch_Setting  gf  switch  tg  switch  :  Switch_Outlet 
end: 

always  prohibited  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
exists  package,  switch  || 

(  PACKAGE_IN_CORRECT_SWITCH_WRONGLY_SET(pac/<age) 
and 

( (  SWITCH  JS_EMPJy (switch)  an d 

package  =  firstfPACKAGES  TO  BE  ROUTED  BY  SWITCH!* .switch)) 
)a§gftry£) 

); 


The  SET_SWITCH  demon  is  a  nondeterministic  expression  of  behaviors.  It  states  that  at  random 
times  the  Switch_Setting  of  some  nondeterministically  selected  switch  should  be  set  to  a 
nondeterministically  selected  Switch_Outlet  of  that  switch.  Picture  a  package  router  mechanism 
with  switches  flapping  at  random. 

The  system  behavior  we  desire  to  specify  is  to  route  packages  correctly  whenever  possible,  given 
the  limitation  of  not  being  able  to  change  a  switch’s  setting  unless  that  switch  is  empty.  The 
constraints  that  state  this  desired  behavior  are  the  require  statement  within  the  body  of  the 
SET_S WITCH  demon  and  the  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE  constraint.  The 
former  rules  out  those  behaviors  that  involve  setting  a  switch  when  it  is  not  empty.6  The  latter  defines 
a  predicate  that  recognizes,  after  the  fact,  that  a  switch  has  not  been  correctly  set.  This  recognition 
occurs  when 


5 

Variable  names  formed  by  appending  distinct  suffixes  to  a  type  name  and  (e  g  ,  source  T  source  ! )  have  the  special 
meaning  of  denoting  distinct  objects 

6 

Since  this  is  the  unique  place  in  the  specification  where  the  setting  of  switches  is  modeled,  we  have  chosen  to  use  a 
require  statement  rather  than  a  global  constraint  (a  stylistic  choice). 
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•  a  package  is  in  a  correct  switch  (that  is,  a  switch  on  route  to  the  package's  destination) 
but  the  switch  is  set  the  wrong  way,  and 

•  at  some  time  m  the  past  there  was  a  chance  to  set  the  switch  tor  that  package ,  that  is,  at 
some  time 

-  tne  switch  was  empty,  and 

■  the  package  was  the  first  ct  those  packages  due  to  be  routed  by  the  switch  (relation 

PACK  AGF.S_TO_BE_RO  UTED_  BY  _S  WITCH). 

By  putting  this  predicate  into  an  always  prohibited,  behaviors  which  lead  to  such  states  are  ruled 
out.  Now  picture  a  package  router  mechanism  with  switches  flapping  in  just  the  right  ways  to  get  only 
desirable  behaviors 


Constraints  and  historical  reference  have  been  used  here  to  characterize  and  rule  out  those 
behaviors  considered  undesirable  We  judge  this  to  be  a  superior  specification  to  one  which  uses  a 
complicated  encoding  of  the  trigger  of  the  switch  setting  demon  to  achieve  the  desired  {and  only  the 
desired)  behaviors. 


3.2.3  Mapping  Away  Constraints  and  Nondeterminism 

To  fully  appreciate  the  implementation  freedoms  afforded  by  the  specification  constructs  of 
constraint  and  nondetermmism.  it  is  necessary  to  understand  the  distinction  between 
nondetermmism  in  the  specification  and  nondeterminism  in  the  implementation.  It  is  obvious  that  in 
our  example  the  SET_SWITCH  demon  is  a  nondeterministic  expression  of  behaviors.  Its  associated 
constraints  serve  to  limit  some  aspects  of  this  nondeterminism  while  completely  eliminating  others. 
For  example  the  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE  constraint  demands  that  a  switch 
be  set  correctly  for  the  package  next  due  to  arrive  when  that  package  finally  arrives.  In  this  respect, 
the  constraint  prescribes  fully  deterministic  behavior. 

On  the  other  hand,  the  constraint  leaves  imprecise  (and  therefore  nondeterministic)  the  statement 
of  when  the  switch  must  be  set.  In  fact,  the  demon/constraint  combination  in  our  example  admits 
behavior  m  which  a  switch  flaps  back  and  forth  until  the  very  last  moment  at  which  it  can  be  correctly 
set.  More  precisely,  the  specification  defines  interval(s)  during  which  the  switch  can  be  freely 
flapping,  provided  that  at  the  end  of  the  (last;  interval  the  switch  is  set  correctly  for  the  package.  Of 
course,  an  acceptable  implementation  could  switch  the  switch  just  once  (if  necessary)  to  set  it 
correctly  for  the  next  package  due,  In  the  implementation  we  derive  for  this  specification,  switches 
are  set  as  early  as  possible  for  the  simple  reason  that  the  beginning  of  the  (first)  interval  is  readily 
defined  in  terms  of  the  available  information  about  packages'  positions,  while  the  end  of  the  (last) 
interval  is  not 

The  most  interesting  case  for  consideration  in  deriving  an  implementation  arises  when 
specification  nondeterminism  and  constraints  combine  to  describe  deterministic  behavior  (as  in  the 
case  of  determining  the  correct  way  to  set  a  switch).  A  range  of  possibilities  present  themselves  for 
mapping  away  such  nondeterminism  and  constraints. 

•  The  "predictive"  solution.  At  one  extreme,  we  might  seek  to  introduce  code  into  all  the 
nondeterministic  choice  points  to  perform  the  necessary  calculations.  These 
calculations  determine  the  choices  that  will  not  lead  to  disaster  arbitrarily  far  into  the 
future.  In  our  example,  this  means  adjusting  SET_SWITCH  to  set  switches  at  the  right 
moments  and  in  just  the  right  ways. 
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•  The  "backtracking'  solution.  At  the  other  extreme,  we  might  derive  a  backtracking 
algorithm  with  the  choice  points  as  the  backtracking  points  and  the  constraints  mapped 
into  search  terminating  checks  at  the  appropriate  places  in  the  program  In  our  example, 
this  means  arbitrary  setting  of  switches  with  backtracking  when  we  discover  that  one  of 
our  constants  is  violated,  in  which  case  we  backtrack  and  try  different  settings 
Unfortunately,  we  do  not  have  the  ability  to  move  packages  backwards  through  our 
network  this  t>  pe  of  solution  is  therefore  rulec  out  for  the  package  router. ' 

The  nature  of  the  domain  of  the  specification  strongly  influences  the  choice  of  method.  The 
capabilities  o'  the  effectors5  (if  there  are  any  in  the  system  being  specified),  the  amount  of  information 
available  for  making  decisions  and  the  desired  amount  of  precomputation  all  affect  the  choice  of 
algorithm  In  our  example,  for  instance,  there  is  no  way  to  return  a  package  to  an  incorrectly  set 
switch  m  order  to  backtrack  However,  static  knowledge  about  the  package  router  network  topology 
is  available  in  the  specification,  so  it  is  possible  to  precompute  the  correct  setting  for  each  switch  and 
destination  bin.  Typically,  as  in  Balzer's  Eight  Oueens  problem,  the  interesting  issue  is  to  produce  an 
algorithm  to  efficiently  perform  the  search,  not  to  make  use  of  the  result  derived  by  the  search  (as  in 
this  example).  We  see  a  general  preference  for  avoiding  backtracking-type  implementations  if  at  all 
possible,  and  in  our  package  router  development  we  find  a  purely  "predictive"  solution. 

Mapping  away  require  SWITCH  _IS_EMPTY(sw/7ch)  within  SET_SWITCH  demon: 

We  simply  add  the  predicate  of  the  requirement  as  a  conjunct  to  the  demon's  trigger,  to  get  the 
following: 


demon  SET_SWITCH[sw/rch] 
trigger  Random ()  and  SWITCH_IS_EMPTY(sw/tch) 
response 
feeain 

update  :  Switch_Setting  qf  switch  tq  switch  :  Switch_Outlet 
§nd: 


It  is  easy  to  see  that  this  mapoing  is  valid,  since  the  added  conjunct  rules  out  precisely  those 
behaviors  in  which  the  SET_SWITCH  demon  would  have  triggered  and  violated  the  requirement. 

To  understand  how  we  might  map  away  the  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
constraint,  we  paraphrase  it  in  order  to  simplify  the  discussion.  Thus, 


7  See  Balzer's  Eight  Oueens  development  [1)  for  a  solution  of  this  nature 

O 

For  example,  switches 
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prohibited  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
exists  package,  switch  || 

(  PACK  AGE  JN_CORRECT_SWITCH_WRONGLY_SET(pacAage) 
and 

( (  SWITCH _!S_EMPTY(sw/fch)  aQd 

package  =  firsttPACK AGES  TO  BE  ROUTED  BY  SWITCHC .switch)) 

asQf  true  ) 


becomes 


always  prohibited  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
exists  package,  switch  || 

P(package)  and  (  Q{switch,  package )  asof  true  ); 


P  corresponds  to  the  presence  of  a  package  at  a  wrongly  set  switch,  and  0  to  an  opportunity  to  set 
the  switch  correctly  for  that  package.  The  paraphrasing  should  be  read  as  "avoid  a  state  in  which  P 
holds  and  there  has  been  a  state  (or  states)  in  which  Q  held."  We  could  seek  to  map  this  into  a 
"predictive"  solution  by  selecting  those  behaviors  in  which,  whenever  Q  is  about  to  hold  (or  holds,  or 
will  hold),  we  do  something  to  ensure  that  P  will  not  become  true  then  or  later.  This  corresponds  to 
setting  a  switch  correctly  for  a  package  whenever  that  package  is  the  first  of  those  due  for  the  switch 
and  the  switch  is  empty. 

Alternatively,  we  could  select  *.n  implementation  which  assures  that  Q  never  holds.  This  implies 
that  no  package  should  ever  become  the  first  of  those  due  at  a  switch  when  that  switch  is  empty.  It 
might  be  possible  to  accomplish  this  by  conspiring  to  prevent  there  ever  being  an  opportunity  to  set 
the  switch  correctly,  say  by  always  delaying  the  exit  of  a  package  from  a  switch  until  it  is  too  late  to 
switch  for  the  next  package.  Note,  however,  that  we  do  not  have  the  power  to  control  the  speed  at 
which  packages  flow  through  the  network. 

The  issue  concerning  the  methods  by  which  an  implementation  preserves  the  integrity  of 
constraints  is  one  of  the  more  difficult  mapping  problems.  At  the  specification  level,  constraints  apply 
to  the  whole  specification.  As  implementors,  however,  we  can  control  the  behavior  of  only  the  portion 
of  the  specification  we  are  implementing.  We  assume  that  our  mission  is  to  implement  this  portion  in 
such  a  way  as  to  ensure  that  such  constraints  are  not  violated  independent  of  the  behavior  of  other 
portions  of  the  system,  as  long  as  they  too  meet  their  specifications,  This  means,  for  example,  that  we 
cannot  expect  (nor  can  we  implement)  the  package  moving  mechanism  to  conveniently  delay 
movement  of  all  packages  so  as  to  avoid  Q  ever  holding.  Some  requirements  are  imposed  on  the 
environment--for  example,  the  constraint  preventing  packages  from  overtaking  one  another  is  entirely 
the  responsibility  of  the  environment-and  we  rely  on  these  invariants  rather  than  having  to  maintain 
them.  But  it  is  our  responsibility  to  implement  our  portion  to  react  to  any  allowable  behavior  of  the 
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other  portions  of  the  specification  in  a  way  that  will  never  allow  any  constraints  to  be  violated. d 

Finally,  we  arrive  at  the  mapped  version  of  the  set  switch  demon,  which  utilizes  "predictive" 
behavior  to  avoid  producing  a  constiamt  violation: 


demon  SET_SWITCH[swifcb] 
trigger  SWITCH  IS  EMPTY(swirch)  and 
exists  package  || 

package  =  firsttPACKAGES  TO  BE  ROUTED  BY  SWITCHC, switch)) 

response 

update  :  Switch_Setting  gf  switch 

tfl  (the pipe  ||  (pipe  =  switch  :  Switch_Outlet  and 
BELOW(package  :  Destination,  pipe) ) ); 


3.3  DERIVED  RELATIONS 


One  of  the  underlying  features  of  Gist  is  that  all  knowledge  is  represented  in  terms  of  objects  and 
relations10  among  those  objects.  Change  is  therefore  represented  by  the  creation  or  destruction  of 
objects  and  by  the  insertion  or  deletion  of  relations  among  them. 

Often  it  is  convenient  to  make  use  of  a  relationship  that  is  derived  from  other  relationships.  Its 
derivation  is  declared  once  and  for  all  and  serves  to  denote  all  the  maintenance  necessary  to 
preserve  the  invariant  between  the  derived  relation  and  the  relations  upon  which  it  depends. 


3.3.1  Example  From  Package  Router 


relation  PACKAGES  TO  BE  ROUTED  BY  SWITCHtoackaoes  |  sequence  of  package. 

switch ) 

definition 
packages  = 

(3  package  || 

(  BELOW  (switch, package  :  At)  and 
BELOW(package  :  Destination, switch)  and 

not  PACK  AGE_IN_CORRECT_SWITCH_WRONGLY_SET (package) ) 

)  ordered  wfl  PACK AGES_EVER_AT_SOURCE(*) ; 


g 

Of  course,  such  a  one-sided  division  of  responsibility  may  not  be  possible  in  a  given  situation  (i  e..  the  specification  is 
unimplementable).  Avoiding  constraint  violation  may  require  cooperation  among  the  portions  of  the  system.  If  so.  the 
specification  must  be  revised  so  that  such  cooperation  is  required  from  each  portion  and  can  therefore  be  relied  upon 


10 


Attributes,  such  as  $witch_Setting,  are  merely  a  syntactically  convenient  and  commonly  useful  form  of  binary  relation 


.i 
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This  relation  defines  PACKAGES_TO_BE_ROUTED_BY_SWITCH  as  a  derived  relation  between 
switches  and  sequences  of  packages.  The  derivation  is  a  predicate  which  relates  the  sequence  of 
packages  to  the  switch. 

For  any  particular  switch,  the  sequence  of  packages  consists  of  those  for  which 

•  the  switch  lies  below  the  package's  current  location  in  the  network. 

•  the  package's  destination  lies  Delow  the  switch,  and 

•  the  package  is  not  in  a  correct  switch  that  is  wrongly  set  ( which  would  impiy  that  the 
package  is  doomed  to  be  misrouted). 

The  ordering  puts  packages  in  sequence  by  the  time  at  which  they  were  located  at  the  source.11 


3.3.2  Mapping  Away  Derhed  Relations 

The  specificational  power  of  the  derived  relation  construct  comes  from  being  able  to  state  a 
derivation  in  a  single  place  and  tc  make  use  of  the  derived  information  throughout  the  specification. 
Since  no  corresponding  construct  is  likely  to  be  available  in  any  implementation  language  we  might 
choose,12  we  must  map  the  derivation  into  explicit  data  structures  and  mechanisms  to  support  all  the 
uses  of  that  information  that  are  scattered  throughout  the  program.  We  have  a  wide  range  of  choices 
as  to  how  we  might  do  this  mapping. 

•  At  one  extreme,  we  might  simply  unfold  the  derivation  at  all  the  places  where  a  reference 
to  the  relation  is  made.  Having  done  this,  we  may  completely  discard  the  relation  and  its 
derivation.  For  example,  after  performing  the  constraint  removal  in  the  previous  section, 
we  could  unfold  PACKAGES _TO_BE_ROUTED_BY_SWITCH  in  its  sole  place  of  use. 
within  the  trigger  of  the  SET_S WITCH  demon.  (This  relatively  simple  step  would  leave 
the  bulk  of  the  development  effort  to  the  mapping  away  of  the  demon  construct )  This 
approach  is  analogous  to  backward  inference,  where  computation  is  performed  on 
demand  and  at  the  site  of  the  need. 

•  At  the  other  extreme,  we  might  retain  the  relation  but  scatter  throughout  the  program  the 
code  necessary  to  explicitly  maintain  the  invariant  between  the  derived  information  and 
the  information  upon  which  it  depends  ("base"  information).  Thus  it  is  necessary  to  find 
all  possible  places  where  a  change  is  made  to  any  of  the  base  information  and  to 
augment  such  places  with  code  to  recalculate  the  derived  information.  This  approach  is 
analogous  to  forward  inference,  where  computation  is  performed  whenever  a 
modification  to  a  relevant  predicate  occurs  and  at  the  site  of  the  change. 


1  'observe  that  the  structure  of  the  network  (a  tree  with  the  source  at  the  root)  and  the  property  that  packages  cannot 
overtake  one  another  combine  to  ensure  that  packages  will  arrive  at  switches  in  the  same  order  in  which  they  were  located  at 
the  source 

Many  ot  the  Artificial  Intelligence  programming  languages  do  provide  facilities  for  implementing  derived  relations  in  terms 
of  inference  processes  For  e*any'“  »n  implementation  of  derived  relations  might  be  provided  in  CONNIVER  [30]  in  terms  ot 
IP-ADDED  or  IFNEEDED  methods  However  ai  programming  languages  in  which  these  facilities  are  pieseni  typically  do  not 
provide  for  the  efficient  execution  one  would  desire  tor  an  optimized  implementation,  nor  do  these  facilities  provide  precisely 
the  semantics  desired  without  the  inclusion  oi  satisfactory  truth  maintenance'  capabilities  [18.  28) 


MAPPINGS 


15 


As  with  mapping  away  historical  reference,  the  nature  of  the  use  of  derived  information  affects  our 
options  and  decisions  In  our  example,  we  might  observe  that  only  the  first  package  of  the  sequence 
of  packages  due  is  ever  required,  and  hence  we  might  seek  to  maintain  only  that  singie  piece  of 
information  'Other  than  the  entire  sequence. 

The  choices  among  the  implementation  alternatives  imply  alternative  trade  offs  between  storage 
and  computation  in  the  resulting  program.  Completely  unfolding  the  derivation  is  tending  towards 
complex  recalculation  with  a  minimum  of  stored  data.  Maintaining  sequences  of  packages  due  at 
each  switch  is  tending  towards  simplifying  calculations  by  simple  maintenance  of  additional  data. 
Maintaining  only  the  first  package  due  at  each  switch  is  a  compromise  between  these  positions. 

Thus,  to  explicitly  maintain  the  relation  PACK  A  GES_TO_BE_ROUTE  D_BY_S  WITCH,  it  is 
necessary  to  determine  the  portions  of  the  specification  that  cause  changes  to  its  "base"  information 

1  Changes  to  the  attributes  At  and  Destination  of  packages,  which  occur  when  a  new 
package  is  created  at  the  source  and  when  movement  of  a  package  occurs. 

2.  Changes  to  the  derived  relation  PACK AGE_IN_CORRECT_SWITCH_WRONGLY_SET. 
which  occur  on  changes  to  the  attributes  At  and  Destination  of  packages  (as  before) 
and  on  changes  to  the  Switch_Setting  attribute  of  switches. 

3.  Changes  to  the  derived  relation  PACKAGES_EVER_AT_SOURCE  which  occur  when  a 
new  package  is  created  at  the  source. 

(Note  that  the  derived  relation  BELOW,  a  property  of  the  static  structure  of  the  routing  network  is  not 
changed  by  any  activity  in  the  specification.) 

In  performing  a  recalculation  when  base  information  changes,  we  may  be  able  to  take  advantage  of 
the  state  of  knowledge  prior  to  the  change  to  incrementally  update  the  derived  information  For 
example,  when  a  new  package  arrives  at  the  source  station,  it  can  be  appended  to  the  end  of  each 
PACKAGE_TO_BE_ROUTED_BY_SWITCH  sequence  for  those  switches  on  the  route  from  the 
source  to  that  package's  destination.  Simply  appending  a  new  element  onto  the  end  of  a  sequence  is 
easier  than  recalculating  the  entire  sequence  afresh.  This  is  an  example  of  a  general  technique  we 
call  "incremental  maintenance,"  derived  from  the  work  of  other  researchers  in  set-theoretic  settings, 
particularly  Paige  and  Schwartz  [33]  and  Paige  and  Koenig  [32],  who  call  the  technique  "formal 
differentiation,"  and  Earley  [19],  who  calls  it  "iterator  inversion."  Balzer's  Eight  Queens  development 
includes  the  incremental  maintenance  of  a  set.  Application  of  the  incremental  maintenance 
technique  to  PACKAGES_TO_BE_ROUTED_BY_SWlTCH  inserts  code  into  the  places  identified 
above.  Hence,  CREATE_PACKAGE  is  transformed  into  the  following: 
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demon  CREATE_PACKAGE[] 
trigger  Random() 
response 
atomic 

create  package. new  II  packaae  new  :  Destination  =  a  bin  and 
package. new  :  At  =  th g  source  : 
loop  switch  j|  BELOW  {package. new  :  Destination,  switch) 
do  update  packages 

Qf  PACKAGES_T0_BE_R0UTED_BY_SWITCH(pack3ges .switch) 
\Q.packages  concatenate  package. new 
end  atomic  ; 


In  some  places  the  introduced  code  can  readily  be  eliminated  because,  although  the  base 
information  is  changing,  the  derived  relation  can  be  determined  to  always  remain  unchanged.  This 
situation  occurs  in  RELEASE_PACK AGE_INTO_NETWORK,  since  moving  a  package  from  the 
source  into  the  first  pipe  does  not  cause  the  package  to  become  located  in  a  correct  switch  wrongly 
set. 

Sometimes  it  is  possible  to  relax  the  restriction  that  the  invariant  embodied  by  the  relation  definition 
need  hold  at  all  times.  When  maintaining  a  derived  relation,  if  the  uses  of  that  relation  do  not 
immediately  follow  the  changes  to  the  base  information,  we  may  delay  the  incremental  maintenance 
provided  that  it  is  performed  before  any  information  retrieval.  Thus,  the  invariant  only  need  hold  at 
the  times  it  is  "used."  To  achieve  this  effect  we  may  apply  either  sophisticated  special-purpose 
transformations  that  deal  with  such  delayed  computation  for  maintenance  or  more  standard  ones  that 
do  "normal"  incremental  maintenance  and  then  apply  code-moving  transformations  to  relocate  the 
maintenance  operations.  The  ne'd  for  this  may  arise  if  incremental  maintenance  leads  to  inserting 
code  into  portions  of  the  specification  over  which  we  have  no  control.  This  possibility  is  apparent  in 
the  above  example,  where  we  have  altered  the  CREATE_PACKAGE  demon,  which  is  in  fact  part  of 
the  environment. 

Hence,  we  must  move  the  maintenance  of  PACKAGESJTO_BE_ROUTED_BY_SWITCH  out  of 
this  demon.  Our  solution  is  to  move  the  maintenance  into  the  beginning  of  the  response  of  the 
RELEASE_PACKAGE_INTO_NETWORK  demon,  which  triggers  on  the  arrival  of  a  package  at  the 
source. 


3.4  DEMONS 


Demons  are  Gist's  mechanism  for  providing  data-directed  invocation  of  processes.  A  demon's 
trigger  is  a  predicate  which  triggers  the  demon  s  response  whenever  a  state  change  induces  a 
change  in  the  value  of  the  trigger  predicate  from  false  to  true. 

Demons  are  a  convenient  specification  construct  for  use  in  situations  in  which  we  wish  to  trigger  an 
activity  upon  some  particular  state  change  in  the  modeled  environment.  Demons  save  us  from  the 
need  to  identify  the  individual  portions  of  the  specification  where  actions  might  cause  such  a  change 
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and  the  need  to  insert  into  such  places  the  additional  code  necessary  to  invoke  the  response 
accordingly.  The  specificational  power  of  the  demon  construct  is  enhanced  by  the  power  of  Gist's 
other  features,  since  the  triggering  predicate  may  make  use  of  defined  relationships,  historical 
reference,  etc. 


3.4.1  Example  From  Package  Router 


demon  RELEASE  PACKAGE  INTO. NET  WORK  [package  new] 

trigger  package,  new  :  At  =  the  source 

response 

begin  ...  end  ; 


We  saw  this  portion  in  Section  3.1.1  as  an  illustration  of  the  use  of  historical  reference.  The  triooer 
of  this  demon  is  a  predicate  that  will  become  true  whenever  a  package  becomes  located  at  the 
source.  When  the  demon  is  so  triggered,  occurrences  of  the  variable  package. new  in  its  response 
are  bound  to  the  instance  of  tne  object  satisfying  that  triggering  of  the  demon. 


3.4.2  Mapping  Away  Demons 

The  demon  RELEASE_PACKAGE_INTO_NETWORK  is  a  special  case  insofar  as  its  triggering 
condition  is  some  external  event,  that  is,  the  relevant  state  changes  are  produced  only  in  the 
environment  portions  of  the  specification.  The  only  mapping  option  is  in  how  to  implement  the 
low-level  details  of  detecting  that  event- -for  example,  by  using  a  polling  loop  or  an  interrupt-driven 
implementation.  More  interesting  from  the  mapping  point  of  view  are  the  other  demons  in  the  portion 
of  the  specification  to  be  implemented  SET_SWITCH  and  DETECT_MISROUTED_ARRIVAL.  where 
the  implementation  must  explicitly  connect  the  production  of  the  conditions  upon  which  to  trigger 
these  demons  with  the  invocation  of  the  demons'  response. 

Mapping  away  such  a  demon  involves  identifying  all  places  in  the  program  where  a  state  change 
might  cause  a  change  of  the  value  of  the  demon's  triggering  predicate  from  false  to  true  and  inserting 
the  code  to  make  such  a  determination  and  perform  the  demon's  response  when  necessary.  This 
mapping  has  much  in  common  with  that  for  maintaining  derived  relations.  Here,  however,  the 
information  to  be  maintained  is  a  truth  value:  its  definition  is  the  trigger  predicate  of  the  demon. 
Whereas  in  a  derived  relation  a  change  would  cause  a  maintenance  operation  of  the  information,  here 
the  demon’s  response  is  to  be  invoked. 

Consideration  of  mapping  away  the  SET_SWITCH  demon  dramatically  illustrates  the  effect  that  the 
order  in  which  constructs  are  eliminated  may  have  on  the  development.  If  that  demon  were  mapped 
away  when  its  trigger  was  still  in  the  form  RandomO,  the  result  would  be  to  augment  every  state 
change  with  a  nondeterministic  choice  of  whether  or  not  to  invoke  that  demon's  response,  Further 
manipulation  of  the  resulting  specification  would  be  severely  hampered,  particularly  in  attempting  the 
removal  of  constraints  by  limiting  nondeterminism.  Obviously  it  is  far  better  to  map  away  the 
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nondeterminism  while  it  is  localized  in  the  demon  (as  discussed  in  Section  3.2)  and  then  to  map  away 
the  demon. 


3.5  TOTAL  INFORMATION 


For  specificational  purposes  it  is  convenient  to  make  free  use  of  any  information  about  the  world 
cescrioed  by  the  specification.  When  implementing  a  specification,  however,  not  all  of  the 
information  is  necessarily  available  at  all  times  The  implementation  specification  oescribes  what  the 
portion  to  be  implemented  may  observe  and  what  it  may  effect 


3.5.1  Example  From  Package  Router 


implement  package_router 
observing 
types 

location,  source,  pipe,  switch,  bin,  package; 
attributes 

Source_Outlet.  Pipe_Outlet.  Switch_Outlet.  Switch_Setting  ; 
predicates 

start  (  a  package  ) .  At  =  th§  source. 
start  (  a  package  )  :  At  =  switch, 
finish  (  a  package  )  :  At  =  switch, 
start  ( a  package  ) :  At  -•  bin  ; 

exists  package  ||  (  package  :  Destination  =  bin  and  package  :  At  =  the  source  ) : 

effecting 

3ttril?UteS 

switch  :  Switch_Setting, 
package  :  At  as Ql  package  :  At  =  lh£  source  ; 
end  implement 


At  several  places  within  the  specification  it  is  assumed  that  the  location  and  destination  of 
packages  anywhere  within  the  network  may  be  determined  (uses  of  At  and  Destination). 
Examination  of  the  implementation  specification  reveals  that  the  only  available  information  about 
these  attributes  of  packages  is  the  arrival  of  a  package  at  the  source,  the  movement  of  a  package  into 
or  out  of  a  switch  or  into  a  bin,  and  the  destination  of  a  package  at  the  time  it  is  located  at  the  source. 


3.5.2  Mapping  Away  Reliance  on  Total  Information 

Mapping  away  this  reliance  is  similar  to  mapping  away  historical  reference- -either  by  introducing 
and  maintaining  auxiliary  data  structures  to  hold  information  that  we  might  need  to  reference  or  by 
finding  ways  to  derive  the  required  information  from  other,  available  information. 
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Mapping  away  references  to  the  Destination  attribute  of  packages  might  be  achieved  by  reading 
each  package's  destination  upon  its  arrival  at  the  source,  explicitly  remembering  that  value  in  the 
implementation,  and  adjusting  retrievals  to  the  destination  attribute  into  retrievals  from  the 
remembered  value  (valid  because  packages'  destinations  remain  static). 

We  could  achieve  the  same  result  in  two  stages  by  first  mapping  in  uses  of  historical  reference, 
replacing  retrievals  of  the  form  package  :  Destination  with 

( package  :  Destination)  asof  package  At  =  (the  source ) 
and  then  mapping  away  these  historical  references  by  explicitly  remembering  the  information. 

Mapping  away  references  to  the  At  attribute  of  packages  could  be  performed  in  a  similar  fashion, 
by  remembering  sequences  of  packages  at  locations  within  the  network.  Maintenance  of  these 
sequences  would  involve  making  use  of  sensor  triggerings  to  indicate  that  packages  have  moved  into 
or  out  of  a  location  and  updating  the  remembered  information  accordingly  In  some  cases  the  lack  of 
perfect  knowledge  may  constrain  our  choice  of  implementation  by  forcing  us  to  select  only  those 
implementations  guaranteed  to  make  no  reliance  upon  information  that  cannot  be  derived  from  the 
observable  behavior. 

As  with  mapping  away  other  constructs,  the  context  in  which  unobservable  information  is  used  and 
the  nature  of  its  use  may  affect  our  decisions  about  how  to  do  the  mapping.  Quite  often  there  are 
potential  interactions  between  how  we  do  this  and  other  kinds  of  mappings;  for  example,  consider  the 
mapping  away  of  the  derived  relation  PACKAGES_TO_BE_ROUTED_BY_SWITCH  (Section  3.3.2). 
Since  we  now  see  that  we  might  need  to  maintain  sequences  of  packages  at  each  location  in  the 
specification,  we  might  wish  to  choose  a  mapping  of  the  derived  relation  which  finds  the  first  package 
due  at  a  switch  by  looking  through  the  sequences  of  packages  at  locations  above  that  switch  to  find  a 
correctly  routed  package.  Thus,  had  we  chosen  some  Other  mapping  of  the  derived  relation,  we 
might  now  be  motivated  to  go  back  and  modify  that  choice  accordingly. 


4.  DEVELOPMENT 


in  the  previous  section,  we  described  some  of  the  high-level  constructs  of  Gist  and  discussed  the 
freedoms  these  constructs  provide  in  both  specification  (by  easing  the  task  of  formally  stating 
requirements)  and  implementation  (by  being  neutral  towards  alternate  implementations).  Our 
emphasis  has  been  more  on  the  implementation  aspects  of  these  high-level  constructs,  and  we  have 
enumerated  several  alternative  implementations  for  each,  These  mappings  are  predicated  on  the 
existence  and  applicability  of  equivalence-preserving  transformations  to  effect  the  desired  changes  to 
the  specification.  In  this  section,  we  argue  that  the  mappings  described  previously  can  be  achieved 
by  applications  of  relatively  straightforward  equivalence-preserving  transformations  and  invocations 
of  general-purpose  mechanisms  (such  as  incremental  maintenance).  To  this  end.  we  present  an 
annotated  development  which  derives  the  mapping  for  historical  reference,  described  in  Section  3.1 . 

Recall  that  we  wish  to  eliminate  historical  references  in  the  following  portion  of  the  package  router 
specification: 


demon  RELEASE  PACKAGE  INTO  NETWQRKfgacxage.new) 
trigger  package  new  :  At  =  the  source 
response 
beam 

if  package. new  :  Destination  -*■ 

( a  package. previous  || 

package-previous  immediately  <  package. new 

wrt  PACK AGES_EVER_AT_SOURCE(*)  )  Destination 

then  WAITf) : 

update  :  At  gf  package. new  tg  (the  source ) :  Source_Outlet 
£Qd  : 

relation  PACKAGES_EVER_AT_SOURCE(packages  ]  sequence  of  package) 
definition  packages  =  (  a  package  )  ordered  wrt  package  :  At  =  ( the  source  ) : 


We  desire  to  produce  the  following  mapped  version  of  the  specification. 


A 


( 
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demo r.  RELE  ASEPACK  AGEJNTO. NET  WORK  [package  new] 
trigger  pac^acr-  new  At  =  thg  source 
response 
begin 

if  package  new  :  Destination  * 
PREVIOUS_PACKAGE_DESTINATlONr) 
then  WAIT[]  . 

update  i  At  gf  package  new  t£>  (thg  sou-ce)  Source_Outlet. 

update  ppdest  in  PREVIOUS_PACKAGE_DESTINATION($) 
to  package. new  Destination 
end; 

relation  PREVIOUS_PACK AGE_DESTIN  ATION(ppdesr  |  bin); 


The  process  of  discovery  of  the  sequence  of  transformations  to  effect  this  change  is  one  of 
interaction  between  implementor  and  system.  The  implementor  provides  guidance  b,  selecting 
transformations  to  be  appuec  and  tne  system  applies  them,  maintaining  the  specification  We 
strongly  expect  the  process  to  be  an  explorator>  one.  involving  exploration  of  several  alternatives, 
retracing  steps  reordering  steps,  and  reapplying  transformations.  Hence  it  is  important  that  the 
system  provide  an  environment  conducive  to  such  exploration. 

in  the  development  that  follows  we  present  a  sequence  of  steps  that  lead  directly  towards  our  goal. 
We  had  to  perform  some  exploration  ourselves  to  discover  this  sequence;  however,  since  our  aim  is 
to  demonstrate  that  such  a  sequence  exists  rather  than  to  show  the  process  of  discovery,  we  do  not 
attempt  to  show  any  of  the  preceeding  discovery  activities. 

In  what  follows,  the  result  of  each  development  step  is  displayed  The  symbol  ►  at  the  side  of  a 
portion  indicates  an  introduction  or  modification. 


4.1  THE  DEVELOPMENT 


The  development's  first  few  steps  take  note  of  the  context  of  use  of  the  historically  defined 
sequence  PACKAGES_EVER_AT_SOURCE  within  the  RELEASE_PACK AGE_INTO_NETWORK 
demon.  In  this  context,  package. previous  is  defined  to  be  the  package  that  precedes  package. new  in 
the  sequence.  One  approach  to  eliminating  the  historical  reference  would  involve  explicitly 
maintaining  the  PACKAGES_EVER_AT_SOURCE  sequence.  Then  it  would  be  necessary  to  search 
that  sequence  for  package. new  and  to  return  package. previous  as  the  immediately  preceding 
package.  However,  a  more  efficient  implementation,  which  avoids  maintaining  the  entire  sequence, 
can  be  derived  by  noting  the  explicit  relationship  between  package. new  and  the 
PACKAGES_EVER_AT_SOURCE  sequence;  package. new  is  precisely  the  last  element.  Thus, 
package. previous  can  be  defined  more  directly  in  terms  of  this  explicit  definition  of  package. new. 
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Our  goal  in  the  development  is  maintenance  of  package-previous.  However,  because  the  definition 
of  package. previous  depends  on  PACKAGES_EVER_AT_SOURCE,  we  must  first  maintain 
PACK  AGES_EVER_AT_SO(JRCE 

Step  1 

Should  we  desire  to  re  express  some  expression  in  terms  of  the  sequence  we  are  about  to 
maintain,  we  should  perform  such  re-expression  prior  to  the  maintenance  (since  maintenance  will 
replace  the  compact  definition  of  the  sequence  with  a  less  transparent  algorithm  for  maintaining  it) 
Thus  the  first  step  in  this  development  involves  the  implementor  making  the  observation  that 
package. new  (in  the  definition  of  package. previous  in  RELEASE_PACK AGE_INTO_NETWORK)  is 
equivalent  to  lastiPACK AGES  EVER  AT  SOURCEO).  The  transformation  step  is  to  replace  that 
occurrence  of  package. new  with  its  equivalent  expression.  The  equivalence  itself  may  be  regarded 
as  a  lemma  requiring  verification.  We  expect  that  the  implementor  will  suggest  automated  assistance 
for  proving  lemmas  of  this  nature  13 

The  following  shows  the  resulting  specification  after  this  transformation  step: 


demon  RELE A SE_P AC KAGE_INTO_NETWORK [package. new] 
trigger  package  new  :  At  =  the  source 
response 

begin 

if  package. new  :  Destination  * 

(  a  package  previous  || 

►  package  previous  immediately  <  lastfPACK AGES  EVER  AT  SOURCEO) 

wrj  PACK  AGES_EVER_AT_SOURCE(‘) ) :  Destination 

then  WAIT[]  : 

update  :  At  of  package. new  tg  (the  source )  Source_Outlet 
end  : 

relation  PACK AGES_EVER_AT_SOURCE(packages  I  seouence  of  package) 
definition  packages  =  (  a  package  )  ordered  wrt  package  :  At  =  ( th§  source  )  : 


Step  2 

A  standard  method  lor  maintaining  a  sequence  such  as  PACKAGES_EVER_AT_SOURCE 
requires  the  introduction  of  a  demon  to  add  new  elements  when  appropriate  and  a  demon  to  remove 
elements  when  appropriate.14  In  this  case,  we  use  a  somewhat  specialized  sequence-maintenance 
transformation  designed  for  sequences  with  the  form 

( a  x  )  ordered  wrt  P(x) 


13 

Alternatively,  this  modification  might  have  been  suggested  by  a  symbolic  evaluation  of  this  portion  of  the  specification 
Thus,  the  initiative  for  suggesting  the  validity  of  this  step  might  have  come  from  the  system  rather  than  from  the  implementor 
Currently,  the  transformation  application  system  we  use  [38J  has  neither  a  theorem  prover  nor  a  symbolic  evaluator  for  Gist, 
both  are  in  the  design  stage 

14Th-  rresponds  to  the  second  mapping  option  from  Section  33  2  However,  rather  than  "scattering  code."  we  use  a 
de  iich  can  be  thought  of  as  a  procedure  which  has  implicit  calls  scattered  about  the  program 
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We  will  drop  the  intermediate  development  steps  that  simplify  the  result  of  this  transformation 
application  by  eliminating  the  demon  that  removes  elements  when,  as  here,  elements  of  that  type  are 
never  destroyed. 

Two  remarks  need  be  made  concerning  this  development  step: 

1  If  PACK  AGES_EVER_AT_SOURCE  is  used  elsewhere  in  the  specification,  then  changes 
we  make  to  it  here  should  be  made  to  a  local  copy  (i  e  .  a  new  relation  with  a  different 
name  but  an  identical  definition). 

2.  The  introduced  demon.  NOTICE_NEW_PACK AGE_AT_SOURCE,  must  execute  before 
demon  RELEASE_PACK AGE_INTO_NETWORK .  which  has  an  identical  trigger. 


demon  RELE A SE_P AC KAGE_INTO_NETWORK [package. new] 
trigger  package. new  :  At  =  the  source 
response 
begin 

if  package. new  :  Destination  * 

(  a  package. previous  || 

►  package. previous  immediately  <  lastIPACK AGES  EVER  AT  SOURCE)*)) 

wrt  PACK AGES_EVER_AT_SOURCE(') )  :  Destination 

thgn  WAIT[]  : 

update  At  gf  package. new  tg  (th£  source) :  Source_Outlet 
end  : 

►  relation  PACKAGES_EVER_AT_SOURCE(packages  I  sequence  of  package)  ; 

►  demon  NOTICE_NEW_PACK AGE_AT_SOURCE[package.new] 

►  trigger  package. new  . At  =  the  source 

►  response  update  packages  in  PACK  AGES_EVER_AT_SOURCE(packages) 

►  to  packages  concatenate  package. new  : 


The  effect  of  the  above  transformation  has  been  to  introduce  the 

NOTICE_NEW_PACKAGE_AT_SOURCE  demon.  This  demon  triggers  whenever  a  package 
becomes  located  at  the  source,  and  it  responds  by  updating  the  packages  in 

PACKAGES_EVER_AT_SOURCE  to  be  the  old  value  of  the  packages  sequence  concatenated  with 
the  new  package. 


Note  that  at  this  stage  the  historical  references  we  were  concerned  with  have  been  eradicated; 
however,  we  are  still  some  distance  from  the  form  of  the  program  we  seek,  and  the  remaining  steps 
cover  that  distance. 
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Step  3 

In  this  step,  the  implementor  isolates  the  portion  defining  package. previous  by  extracting  the 
definition  of  package. previous  from  the  demon  and  defining  a  new  unary  relation  which  is  true  of  only 
the  penultimate  element  of  PACKAGES_EVER_AT_SOURCE(').  This  definition  is  accomplished  by 
application  of  a  standard  fold  into  relation  definition  transformation  One  form  of  fold  transformation 
takes  an  object  expression  and  replaces  it  with  a  retrieval  from  a  relation  defined  as  that  obiect 
expression.  Application  of  this  transformation  yields  the  following 


demon  RELE ASE_P AC K AGE JNTO_NETW OR K [package  new] 
tngafil  package. new  :  At  =  the  source 
response 
begin 

if  package. new  :  Destination  * 

►  PREVlOUS_PACK  AGE(‘)  :  Destination 
then  WAIT[] ; 

update  :  At  gf  package. new  t_Q  (the  source) :  Source_Outlet 
end  : 

relation  PACK AGES_EVER_AT_SOURCE(packages  |  sequence  of  package!  : 

►  relation  PREVIOUS_PACK fkGE(prev_package  |  PACKAGE) 

►  definition 

►  prev_package  -  (the  package. previous  II 

►  package. previous  immediately  <  lastfPACK  AGES  EVER  AT  SOURCEO) 

►  wrt  PACKAGES_EVER_AT_SOURCE(*) ) : 

demon  NOTICE  NEW  PACKAGE  AT  SOURCEfoackaoe  new! 
trigger  package,  new  :  At  =  the  source 

response  update  packages  in  PACK  AGES_EVER_AT_SOURCE(paci<ages) 
t q.  packages  concatenate  package. new  : 


Step  4 

To  accomplish  the  next  step,  maintaining  PREVIOUS_PACKAGE  itself,  we  again  exercise  the 
second  mapping  option  from  Section  3.3. 2. 
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demon  RELEASE_PACKAGE_INTO_NETWORK[pacAage.new] 

trigger  package. new  :  At  =  the  source 
response 
begin 

if  package  new  :  Destination  *  PRFVIOUS.PACK  AGE(’) :  Destination 
then  WAIT[] ; 

update  :  At  el  package. new  tg  (the  source) :  Source.Outlet 
end  ; 

relation  PACKAGES_EVER_AT_SOURCE(packages  |  sequence  el  package)  . 

►  relation  PREVIOUS_PACK  AGE(prev _package  |  package)  ; 

demon  NOTICE  NEW  PACKAGE  AT  SOURCEroacJ<aoe.new] 
trigger  package. new  :  At  =  the  source 

response 

atomic 

update  packages  in  PACK AGES_EVER_AT_SOURCE(pacKages) 
to  pacxaaes  concatenate  package. new  : 

►  update  prev_package  in  PREVIOUS_PACK  AGE($) 

►  to  ( the  package. previous  II 

►  package. previous  immediately  < 

►  iast(PACKAGES_EVER_AT_SOURCE(*)  concatenate  package  new) 

►  wrt  PACKAGES  EVER  AT  SOURCE)*)  concatenate  package  new ) 
end  atomic  ; 


Code  for  the  purpose  of  maintaining  PREVIOUS_PACK AGE  has  been  introduced  into  the 
NOTICE_NEW_PACKAGE_AT_SOURCE  demon  at  the  point  where  a  modification  is  made  to  the 
relation  PACK AGES_EVER_AT_SOURCE,  upon  which  PREVIOUS.PACK AGE  depends.  The 
effect  of  this  transformation  is  to  unfold  the  definition  of  PREVIOUS.PACKAGE  to  the  possible 
points  of  change  (in  this  case,  only  one).  That  is  after  every  possible  change  to  relevant  data  code  is 
introduced  to  perform  an  entire  recalculation,  determining  if  there  was  actually  a  change  to 
PREVIOUS.PACKAGE. 

The  code  to  update  the  value  of  PREVIOUS_PACKAGE  lies  inside  a  newly  created  atomic,  which 
is  a  Gist  construct  that  allows  a  "macro"  state  change.  That  is,  several  data  base  modifications  can 
be  made  inside  an  atomic,  within  which  all  changes  occur  with  respect  to  the  state  preceding  the 
atomic  and  no  state  transition  occurs  until  the  atomic  is  completed.  Thus,  since  the  updated  value  of 
PREVIOUS.PACKAGE  wishes  to  refer  to  the  updated  value  of  PACK  AGES_EVER_AT_SOURCE,  it 
must  reproduce  the  modification  to  PACKAGES_EVER_AT_SOURCE  because  the  modification  is 
not  reflected  inside  the  atomic.  The  update  of  PREVIOUS.PACKAGE  is  to  "the  package 
immediately  preceding  the  last  package  in  the  sequence  consisting  of  the  old  value  of 
PACK  AGES_EVER_AT_SOURCE  concatenated  with  the  new  package." 
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Step  5 

Having  achieved  the  maintenance  of  PREVIOUS_PACK AGE  we  now  perform  a  local 
simplification  on  the  code  that  was  inserted  to  do  that  maintenance  The  transformation 

(the  obj. previous  ||  obi. previous  immediately  <  obi. last 

wrt  ( sequence  concatenate  <obj.last> )) 

(the  obj. previous  ||  obj. previous  =  lasl(sequence)) 

is  applied  to  simplify  the  expression  of  the  value  to  which  prev _pacKage  is  updated.  This 
transformation  is  clearly  derivable  from  the  properties  of  concatenate  and  immediately  <.  It  can  be 
expressed  as  a  chain  of  simpler  transformations  dealing  with  these  constructs  This  transformation 
can  be  verified  in  several  ways.  If  it  is  not  listed  in  our  catalogue  of  already  verified  transformations, 
we  can  describe  the  change  ourselves  and  require  either  that  its  correctness  be  verified  or  that  the 
equivalent  chain  of  simpler  transformations  be  discovered.  (The  latter  technique  is  under 
investigation  by  another  member  of  our  group  [23]). 

The  result  of  the  transformation  (however  verified)  is  as  follows: 


demon  RELEASE  PACKAGE  INTO  NETWORKfpacfraoe.new) 
triaaer  package. new  :  At  =  the  source 
response 
begin 

if  package. new  :  Destination  *  PREVIOUS_PACK  AGE(*) :  Destination 
then  WAIT[] ; 

update  :  At  fif  package. new  Jg  (lh£  source)  :  Source_Outlet 
end  ; 

relation  PACK  AGES_EVER_AT_S0URCE(pacfc3pes  |  sequence  qI  package)  : 

relation  PREVIOUS_PACKAGE(prev _ package  |  package)  ; 

demon  NOTICE  NEW  PACKAGE  AT  SOURCE  [package,  new] 
trigger  package. new  :  At  =  the  source 

response 

atomic 

update  packages  jn  PACKAGES_EVER_AT_SOURCE(pacfcages 
10  packages  concatenate  package,  new  ; 
update  prev.package  in  PREVIOUS_PACKAGE($) 

10  ( th£  package. previous  || 

►  package. previous  - 

►  last!  PACKAGES  EVER  AT  SOURCES) 


end  atomic : 
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Step  6 

This  step  applies  a  trivial  local  simplification  to  the  code  resulting  from  Step  5.  We  intend  that  our 
transformation  system  perform  such  simplifications  automatically.  The  simplification  is 

(the x  II  X  =  EXPR)  -->  EXPR 

This  transformation  requires  that  the  type  of  EXPR  be  equal  to  or  a  subtype  of  x.  and  that  EXPR  be  a 
deteimimstic  expression  These  properties  are  easily  proved,  the  former  because  Gist  is  strongly 
typed,  the  latter  because  last  of  a  deterministic  sequence  must  be  deterministic,  and 
PACKAGES_EVER_AT_SOURCE(’l  can  be  shown  to  be  a  deterministic  sequence. 

The  resulting  code  is  as  follows: 


demon  RELEASE  PACKAGE  INTO  NETWORK[pac*age.new] 
trigger  package  new  :  At  =  the  source 
response 
begin 

il  package. new  :  Destination  *  PREVIOUS_PACKAGE(*) :  Destination 
then  WAITQ  : 

update  :  At  £f  package. new  to  (the  source ) :  Source_Outlet 
end : 

relation  PACK  AGES  JEVER_AT_SOURCE(pac/<ages  |  sequence  gf  package)  : 

relation  PREVIOUS_PACKAGE(prev j oackage  f  PACKAGE) ; 

jjgman  NOTICE_NEW_P  AC  KAGE_AT_SOURCE[pacXage.  new] 
trigger  package. new  :  At  =  the  source 
response 
atomic 

update  packages  in  PACKAGES_EVER_AT_SOURCE(pac*ages) 
to  packages  concatenate  package. new  ; 
update  prev  package  in  PREVIOUS_PACK  AGE($) 

►  10  ia£l(  PACKAGES_EVER_AT_SOURCE(*) ) 

end  atomic : 


Step  6  concludes  the  second  sequence  of  steps  At  this  point  we  once  again  take  stoc  of  the 
situation  and  plan  a  few  "cleanup"  steps.  An  observation  that  motivates  the  cleanup  is  ihat  the 
explicit  maintenance  of  PREVIOUS_PACKAGE  involves  the  expression 

lastf  PACKAGES_EVER_AT_SOURCE(*) ) 

Our  cleanup  will  be  to  fold  this  expression  into  a  new  relation,  explicitly  maintain  that  relation,  and 
simplify- -Steps  7  through  9  (akin  to  the  sequence  of  steps  we  have  just  completed). 


'V"  ~  v  • 
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Step  7 

As  in  Step  2,  we  isolate  the  interesting  portion  from  the  rest  of  the  specification  by  extracting  it  and 
using  it  to  create  the  definition  of  a  new  relation:  lastfPACKAGES  EVER  AT  SOURCECI)  becomes 
the  definition  of  the  new  relation  LAST_PACKAGE. 


demon  RELEASE  PACKAGE  INTO  NETWORKfpacKaoe.newl 
trigger  package. new  :  At  =  the  source 
response 
beoin 

jf  package. new  :  Destination  *  PREVIOUS_PACKAGE(*) :  Destination 
Then  WAITfl : 

update  :  At  qI  package, new  tfi  (the  source) :  Source_Outlet 
end  ; 

relation  PACKAGES_EVER_AT_SOURCE(pac/<ages  |  sequence  of  package)  ; 

relation  PREVIOUS_PACKAGE(orev joackage  |  PACKAGE)  : 

Gsmon.  NOTICE_NEW_PACKAGE_AT_SOURCE[pacKage.new] 
triooer  package. new  :  At  =  the  source 
response 

atomic 

update  packages  in  PACK  AGES_EVER_AT_SOURCE(packages) 
tg  packages  concatenate  package. new  ; 

update  prev_package  in  PREVIOUS_PACK  AGE($) 

►  tg  LAST_PACKAGE(*) 

end  atomic  ; 


►  relation  LAST_PACKAGE(/asf _ package  |  package) 

►  definition 

►  last  package  =  l§s!(  PACKAGES_EVER_AT_SOURCE(') ) : 


Step  8 

Maintaining  LAST_PACKAGE  involves  mapping  a  derived  relation.  We  will  again  exercise  the 
second  mapping  option  from  Section  3.3.2. 
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demon  RELEASE  PACKAGE  INTO  NETWORK[oackaoe.new1 
trigger  package,  new  :  At  =  the  source 
response 
begin 

jf  package  new  .  Destination  *  PREVIOUS_PACKAGE(*) :  Destination 
th£n  WAIT[] ; 

update  :  At  gt  package. new  t£  (the  source ) :  Source_Outlet 
end  ; 

relation  PACK  AGES_EVER_AT_SOURCE(packages  |  sequence  of  package)  ; 

relation  PREVIOUS_PACKAGE(prev _package  |  PACKAGE) ; 

demgQ  NOTICE_NEW_PACKAGE_AT_S0URCE[package.new] 
trigger  package. new  :  At  =  the  source 
response 
atomic 

update  packages  m  PACKAGES_EVER_AT_SOURCE(packages) 
tfi  packages  concatenate  package. new  ; 
update  prev_package  in  PREVIOUS_PACKAGE($) 
tfl  LAST_PACKAGEC)  ; 

►  update  last  package  in  LAST  PACKAGED) 

►  to  last(  PACKAGES  EVER  AT  SOURCEf*)  concatenate  <  package. new  >  ) 
end  atomic  ; 

►  relation  LAST_PACKAGE(/asf _package  |  package)  ; 


We  have  invoked  precisely  the  same  transformation  as  in  Step  4,  where  we  maintained 
PREVIOUS_PACKAGE.  Again,  the  maintenance  of  LAST_PACKAGE  occurs  inside  the  atomic  of 
NOTICE_NEW_PACKAGE_AT_SOURCE  and  is  thus  defined  in  terms  of  the  old  value  of 
PACKAGES_EVER_AT_SOURCE  concatenated  with  the  new  package 

Step  9 

This  step  again  invokes  a  trivial  local  simplification  of  the  form 
lastfseouence  concatenate  <element»  -■>  element 
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demon  RELEASE_PACKAGE_INTO_NETWORK [package. new] 
trigger  package,  new  :  At  =  th£  source 
response 
begin 

if  package  new  :  Destination  *  PREVIOUS_PACKAGE(') :  Destination 
then  WAIT[] ; 

update  At  gf  package  re w  tg  (th£  source) :  Source_Outlet 
end  : 

relation  PACK  AGES_EVER_AT_SOURCE(packages  |  sequence  gf  package)  ; 

relation  PREVIOUS_PACKAGE(prev _package  j  package)  ; 

demon  NOTICE  NEW  PACKAGE  AT. SOURCEfpackage.new] 
trigger  package  new  :  At  =  the  source 
response 
atomic 

update  packages  in  PACKAGES_EVER_AT_SOURCE(packages) 
to  packages  concatenate  package  new.  ; 
update  prev_package  in  PR£VIOUS_PACK AGE($) 
tg  LAST_PACK  AGE(*) ; 
update  last_package  in  LAST_PACK  AGE($) 

►  iq  package  new 

end  atomic  ; 

relation  L AST_P AC KAGE(/asf_pack age  |  package)  ; 


Step  9  completes  the  third  small  sequence  of  transformation  steps,  and  we  appear  to  have 
achieved  as  much  local  simplification  as  possible  Next  we  will  make  a  simplification  based  upon  a 
more  global  observation 

Step  10 

By  observing  (and  having  the  system  prove)  that  PACK AGES_EVER..AT_SOURCE  is  maintained 
but  never  referenced,  we  can  remove  the  relation  entirely,  with  the  following  result: 
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demon  RELEASE_PACKAGE_INTO_NETWORK[pacfcage.new] 
trigger  package,  new  :  At  =  the  source 
.rS.Sfifln.Sg 
begin 

if  package  new  :  Destination  *  PREVIOUS_PACKAGE(*) :  Destination 
then  WAIT[j ; 

update  :  At  q[  package. new  (g  (the  source) :  Sou  rce_Outlet 

sod: 

relation  PREVIOUS_PACKAGE(prev _package  |  package)  ; 

dgmfln  NOTICE_NEW_PACKAGE_AT_SOURCE[pac/cage.new] 
trigger  package. new  :  At  =  the  source 
response 
atomic 

update  prev_package  in  PREVIOUS_PACKAGE($) 

1q  LAST_PACKAGE(*) ; 
update  last_package  in  LAST_PACKAGE($) 
fa  package,  new 
end  atomic  ; 

relation  LAST_PACKAGE(/asr _ package  |  package)  ; 


4.2  DISCUSSION 


4.2.1  Summary  of  Development  Steps 

Maintain  PACKAGES_EVER_AT_SOURCE  (Step  2);  but  prior  to  doing  so.  re-express 
package. previous  in  terms  of  PACKAGES_EVER_AT_SOURCE  (Step  1). 

Isolate  the  expression  for  package. previous  (Step  3)  and  maintain  it  (Step  4);  then  perform  local 
simplifications  (Steps  5  and  6). 

Isolate  the  expression  for  !asl(PACKAGES_EVER_AT_SOURCE(*))  (Step  7),  maintain  it  (Step  8), 
and  then  perform  local  simplification  (Step  9)  and  global  simplification  (Step  10). 


4.2.2  Remaining  Minor  Steps 

The  major  objective  of  this  part  of  the  development,  namely,  the  elimination  of  historical  reference 
in  a  respectably  efficient  manner,  has  been  attained.  The  implementation  is  not  yet  in  the  precise 
form  of  the  stated  goal  of  this  development;  the  steps  to  achieve  this  form  are  similar  to  those  already 
presented.  They  involve  noticing  that 


Jt 
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1  -  the  NOTICE_NEW_PACK AGE_AT_SOURCE  demon  has  the  same  trigger  as 
RELEASE_PACK  AGE_INTO_NETWORK,  Thus  their  responses  can  be  combined 
(taking  care  that  proper  order  is  preserved). 

2.  only  the  Destination  attribute  of  the  previous  package  >s  desired:  thus  it  is  not  necessary 
to  save  the  identity  of  the  package,  only  its  destination. 

3.  because  LAST_PACKAGE  equals  package. new  inside  the  response  of  the 
RELEASE_PACKAGE_INTO_NETWORK  demon,  we  do  not  need  to  explictly  remember 
LAST_PACKAGE  (or  its  destination). 


4.2.3  Summary 

The  objective  of  this  section  was  to  demonstrate  that  high-level  mappings  can  be  accomplished 
through  judicious  application  of  low-level  transformations.  The  other  mappings  described  in  Section 
3  are  similarly  achievable. 


RELATED  WORK 
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S.l  TRANSFORMATIONAL  METHODOLOGY 

The  transformational  methodology  that  we  follow  is  one  of  several  approaches  to  improving 
software  development.  The  research  we  have  described  relates  most  closely  to  those  efforts 
involving  some  form  of  mapping  between  constructs  on  different  levels  of  programming.  In  this 
section,  we  comment  on  several  such  efforts. 

Burstall  and  Darlinoton.  Their  early  schema-based  transformations  [12, 16]  served  to  do 
optimization  tasks  of  recursion  removal,  common  subexpression  elimination,  loop  combination,  in¬ 
line  procedure  expansion,  and  introduction  of  destructive  operations  to  reuse  released  storage. 
These  techniques  were  built  into  a  system  which  allowed  the  user  to  select  the  optimization  process 
to  be  attempted  next.  Burstall  and  Darlington  made  the  observation  that  manipulations  are  better 
done  on  higher  level  programs  before  mappings  down  to  the  next  level  (recursion  to  iteration, 
procedure  expansion,  etc.)  are  performed. 

Their  later  work  concentrated  upon  manipulation  of  recursion  equations  and  achieved  efficiency 
improvements  by  altering  the  recursion  structure  [10].  The  changes  were  primarily  radical 
restructuring  of  algorithms,  achieving  efficiency  at  the  expense  of  modularity  and  clarity.  These  ideas 
were  embodied  in  an  experimental  system  that  relied  upon  a  semiautomatic  approach.  The  system 
proposed  possible  steps  to  take,  and  the  user  selected  or  rejected  avenues  for  exploration  [15]. 
Another  system  based  on  the  same  ideas  was  developed  to  tackle  larger  scale  examples  by  requiring 
(and  permitting)  the  user  to  provide  guidance  in  a  more  high-level  fashion  [20.  22].  Darlington 
extended  the  underlying  approach  to  be  able  to  go  from  specifications  initially  containing  set  and 
sequence  constructs  into  recursion  equations  [13.  14).  Darlington's  research  in  these  and  related 
directions  continues. 

We  see  many  issues  crucial  to  the  overall  transformational  methodology  being  pursued  in  this 
research.  The  most  significant  difference  (from  our  own  efforts)  lies  in  the  nature  of  the  specification 
language.  Their  language.  HOPE  [11]  (formerly  NPL),  is  purely  applicative  in  nature;  although  they 
are  able  to  investigate  many  of  the  issues  of  transformational  development  of  software  within  this 
applicative  framework,  we  believe  that  an  applicative  specification  language  is  limited  in  the  nature  of 
the  problems  to  which  it  is  suited.  In  contrast,  our  language.  Gist,  has  been  constructed  explicitly  to 
express  a  wide  range  of  tasks. 

Manna  and  Waldinoer.  Their  DEDALUS  system  [29]  comprised  a  fully  automated  approach  to 
deriving  algorithms  in  some  target  language  from  specifications  in  some  specification  language  rich 
with  constructs  from  the  subject  domain  of  the  application.  The  examples  they  have  dealt  with  involve 
specifications  using  set  theoretic  constructs:  these  specifications  become  synthesised  into  recursive 
procedures  and  in  turn  into  iterative  procedures  (in  a  LISP- like  language).  In  their  investigations  the 
scale  of  the  problems  has  been  rather  small  because  of  their  desire  to  do  the  synthesis  in  a  fully 
automatic  fashion.  In  contrast,  the  emphasis  of  our  research  has  been  to  investigate  tools  which  will 
assist  a  skilled  developer  to  derive  implementations  from  specifications.  We  hope  that  as  we  gain 
more  experience  with  this  activity  we  will  incrementally  introduce  more  automation  into  our  tools. 

CIP.  The  CIP  (Computer-aided  Intuition-guided  Programming)  group  at  Munich  [5, 6]  advocates 
using  machine  support  to  do  the  bookkeeping  tasks  in  development  and  documentation,  with  a 
human  user  providing  the  intuition  to  guide  this  process.  Their  specification  language  is  built  upon  a 
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kernel  of  recursive  functions  together  with  transformations  to  manipulate  the  kernel.  Language 
extensions  can  be  defined  in  terms,  of  the  kernel  by  application  of  the  transformations  Thus  new 
constructs  can  be  defined  for  both  implementation  (eg.,  loops,  assignments,  blocks)  and 
specification  (e.g.,  "descriptive  expressions"  corresponding  to  Gist's  (thg  *  ||  P(x )) .  abstract  data 
types,  nondeterministic  expressions  which  could  denote  zero,  one  or  more  objects)  [7]  In  order  to 
transform  programs  making  use  of  these  introduced  constructs,  the  defining  transformations  are 
used  to  convert  the  constructs  into  recursive  procedures  (where  substantial  efficiency  improvements 
may  be  achieved  by  applying  the  kernel  transformations)  before  mapping  them  back  into  the  desired 
constructs  As  with  the  Burstall  and  Darlington  work,  there  is  much  overlap  between  this  work  and 
our  own  in  the  approach  and  the  research  avenues  being  explored. 

SETL.  This  work  is  based  on  the  idea  of  augmenting  specifications  with  guidance  to  a 
sophisticated  compiler  to  suggest  data  representations  [17.  35).  SETL  is  based  around  libera!  use  of 
tuples,  sets,  and  functions  (and  operations  upon  them)  User-provided  declarations  direct  the 
compiler  to  select  appropriate  data  structures  (from  a  pre  existing  library)  The  sophisticated 
compiler  automatically  generates  the  code  to  implement  the  operations  on  these  representations 
The  group  continues  to  investigate  the  usefulness  of  this  approach  and  the  extent  to  which  currently 
user-made  decisions  can  be  automated  [34],  As  mentioned  in  Section  3.  we  are  able  to  incorporate 
into  our  framework  their  techniques  for  dealing  with  some  "data"  freedoms,  which  should  save  us 
from  the  "reinventing  the  wheel"  syndrome. 

Neighbors  He  advocates  a  methodology  based  on  picking  some  domain  of  tasks,  developing  a  set 
of  reusable  components  for  that  domain,  and  then,  when  faced  with  a  specific  problem  in  that 
domain,  combining  and  tailoring  those  components  for  that  problem  [31].  While  this  differs  from  the 
methodology  we  follow,  parallels  can  be  drawn  between  some  of  the  details  of.  and  observations 
drawn  from,  each  approach.  Neighbors'  "refinements."  which  convert  "components"  'objects  o' 
operations)  from  one  domain  into  another  domain  closer  to  implementation,  correspond  to  cjr 
mappings  to  eliminate  Gist  constructs.  Although  the  constructs  expressed  in  the  components  o; 
domains  he  has  so  far  considered  are  not  as  rich  as  those  within  Gist,  he  has  been  led  to  similar 
observations,  for  example,  that  optimizations  (his  "customising"  by  transformation)  are  best  dene  at 
the  appropriate  levels,  that  retaining  the  refinement  record  is  helpful  to  maintenance,  and  tnat  the 
choice  of  "refinement"  (mapping  to  us)  for  one  component  may  influence  anc  interact  with  the 
refinement  of  other  components. 


5.2  SPECIFICATION 


We  believe  that  the  approach  to  constructing  our  specification  language,  and  the  resulting 
combination  of  features,  is  new.  However,  analogies  of  individual  features  can  be  found  in  other 
languages. 

•  The  relational  data  base  model  espoused  by  Smith  and  Smith  [37], 

•  Temporal  logic,  at  least  in  its  use  to  talk  and  reason  about  the  past.  Gist  s  use  of 
historical  reference  is  very  close  to  the  approach  of  Sernadas  in  his  temporal  process 
specification  language,  DMTLT  [36], 

•  Automatic  demon  invocation,  seen  in  the  Al  languages  PLANNER  and  Qiisp  [9], 

•  Nondeterminism  in  conjunction  with  constraints- closest  to  nondeterministic  automata 
theory  [27j. 
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•  Operational  semantics  and  closed  system  assumptions  as  seen  in  simulation  languages 
[8]  Zave's  executable  specification  language  PAISLEY  [40,  41]. 


5.3  GROUP  EFFORTS  AT  ISI 


Below  is  an  outline  of  the  efforts  that  our  group  at  ISI  has  performed.  References  to  these  subjects 
occur  earlier  in  this  report,  we  gather  them  together  here  to  clarify  the  relation  of  the  mapping 
component  to  the  whole. 

•  Methodology.  An  outline  of  our  overall  approach  is  given  in  [3].  A  detailed  case  study  of 
a  single  development  (the  Eight  Queens  problem)  is  presented  in  [1], 

•  Specification  language  Some  requirements  of  a  specification  language  suitable  for 
system  specification  can  be  found  in  [2],  and  [25]  provides  a  description  of  Gist,  the 
language  we  are  developing  to  satisfy  those  requirements. 

•  Supporting  system  for  development.  The  POPART  system,  which  produces  tools  to 
support  our  development  process,  is  described  in  [39],  and  [38]  contains  a  detailed 
discussion  of  issues  relating  to  making  the  development  process  itself  a  formal  object  A 
mechanism  for  automatically  producing  ("jittering")  the  many  mundane  steps  that  occur 
in  a  development  is  discussed  in  [23].  Research  towards  automating  the  higer  levels  of 
transformational  development  is  presented  in  [24], 

•  Construction  gf  specifications.  Research  aimed  at  supporting  the  construction  of  formal 
specifications  from  informal  natural  language  expositions  is  reported  in  [4] 


i 


A 


f 

t 

6.  CONCLUSIONS 

The  primary  goal  of  the  research  described  in  this  paper  has  been  the  investigation  of  how  to  map 
away  uses  of  Gist's  high-level  specificational  constructs.  An  example  specification  provides  the 
underlying  motivation  for,  and  an  illustration  of.  our  efforts.  However,  we  have  considered  the  task  in 
more  general  terms;  in  so  doing,  we  have  provided  a  further  illustration  of  the  utility  of  Gist  s 
constructs  for  specification. 

The  usefulness  of  our  efforts  can  only  be  judged  within  the  larger  framework  of  the 
Transformational  Implementation  approach  to  software  development.  As  a  part  of  this  overall 
methodology  for  developing  software,  our  efforts  depend  on  the  success  of  that  methodology.  It 
remains  to  be  demonstrated  that  Gist  specifications  can  be  readily  constructed  and  manipulated  and 
that  the  result  of  our  mappings  (a  Gist  specification  with  all  uses  of  its  high-level  constructs  mapped 
away)  can  readily  be  converted  into  an  efficient  program  in  a  conventional  implementation  language. 
Our  group  is  involved  in  continuing  research  in  these  areas. 

We  have  described  techniques  for  mapping  away  each  of  Gist's  high-level  constructs,  suggested 
criteria  for  selecting  one  technique  over  another  in  terms  of  the  specification  and  the  desired  nature 
of  the  implementation,  and  demonstrated  that  the  mappings  are  derivable  by  the  application  of  low- 
level  equivalence-preserving  transformations.  However,  some  major  tasks  remain.  Important  among 
these  are  the  tasks  of  actually  compiling  a  sizable  library  of  transformations  for  use  in  mapping 
activities  and  developing  mechanisms  to  assist  an  implementor  to  carry  out  the  mappings.  We  are 
now  confident,  however,  that  it  will  indeed  be  possible  to  both  describe  and  collect  such 
transformations  and  to  make  use  of  them  in  actual  developments. 

While  pursuing  the  research  described  in  this  paper,  we  confronted  several  issues  that  bear  further 
investigation. 

■  The  order  in  which  constructs  are  mapped  away  seems  to  be  important.  We  do  not 
expect  there  to  be  a  "best"  order  independent  of  the  problem.  There  seems  to  be  an 
opportunistic  component  of  transformational  program  development. 

•  Although  there  might  be  standard  mappings  to  convert  uses  of  one  construct  into  uses  of 
another,  we  do  not  think  that  a  viable  approach  could  be  based  on  converting  uses  of  all 
types  of  constructs  into  uses  of  just  one  type  and  then  concentrating  on  mapping  away 
that  construct. 

•  The  need  to  map  two  separate  constructs  occurring  in  disparate  sections  of  the 
specification  may  lead  to  sharing  of  data  structures  or  procedures.  Thus  the  selections 
of  mappings  cannot  be  made  independently;  each  might  derive  an  optimal 
implementation  for  its  instance,  yet  together  they  provide  a  suboptimal  implementation 
for  both.  It  is  unlikely  that  we  will  be  able  to  forsee  all  the  ramifications  of  mapping 
decisions.  Hence,  we  may  expect  to  cycle  back  through  the  development  process  to 
adjust  some  of  our  earlier  choices.  This  further  highlights  the  need  for  machine  support 
during  the  development  process.  With  such  support,  exploratory  development  should  be 
a  relatively  painless  activity. 

•  Dealing  with  the  distinction  between  system  (the  portion  of  the  specification  to  be 
implemented)  and  environment  (the  remaining  portions  of  the  specification  which 
establish  the  framework  within  which  the  system  will  operate)  is  very  difficult.  Often, 
mappings  distribute  code  not  only  through  the  system  portion  of  the  specification,  but 
also  through  the  description  of  the  environment,  thus  modifying  its  behavior.  This 
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indicates  that  the  implementation  chosen  requires  cooperation  from  the  environment. 
Since  such  cooperation  cannot  be  assured  (because  it  was  not  part  of  the  specification), 
either  another  implementation  must  be  chosen  or  the  specification  must  be  renegotiated 
(as  is  often  necessary  when  implementation  problems  arise). 


I.  GIST  SPECIFICATION  OF  PACKAGE  ROUTER 


Key  to  font  conventions  and  special  symbols  used  in  Gist 


symbol  meaning 


example 


|  of  type 

||  such  that 

may  be  used  to  build  names 
concatenates  a  type  name  with  a 
suffix  to  form  a  variable  name, 
with  the  semantics  that  such 
variables  with  distinct  suffixes 
denote  distinct  objects. 


obj  I  t  •  object  obj  of  type  t 

(  an  integer  ||  ( integer  >  3 ) )  -  an  integer  greater  than  3 

this_name 

integer.  1 


tents 


meaning  example 


underlined 

SMALL  CAPITALS 
lower  case  italics 

UPPER  CASE  BOLDFACE 


Mixed  Case  Boldface 


key  word 
type  name 
variable 
action,  demon, 
relation,  and 
constraint  names 
attribute  names 


begin,  definition,  if 

INTEGER 

x 

SET.SWITCH 


Destination 


Package  Router  Specification  in  Gist 


The  network 

type  location()  supertvpe  Qf 
<  souRCE(Source_Outlet  |  pipe); 

Gist  comment  -  the  above  line  defines  source  to  be  a  type  with  one  attribute.  Source.Outlet.  and  only 
objects  of  type  pipe  may  serve  as  such  attributes  gng  comment 


piPE(Pipe_Outlet  |  (switch  union  bin)  ::uniaue): 

SWiTCH(Switch_Outlet  |  pipe  :2,  Switch_Setting  |  pipe) 
where  always  reouired 

switch  :  Switch_Setting  =  switch  :  Switch_Outlet  end: 

bin() 

> ; 


Spec  comment  ■  of  the  above  types  and  attributes,  only  the  SWITCH_SETTING  attribute  of  switch  is  dynamic 
in  this  specification;  the  others  remain  fixed  throughout  £ng  comment 

Gist  comment  •  by  default,  attributes  (e  g.,  Source.Outlet)  of  types  (e  g  ,  source)  are  functional  (e  g  ,  there  is 
one  and  only  one  pipe  serving  as  the  Source.Outlet  attribute  of  the  source)  The  default  may  be  overridden,  as 
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occurs  in  the  Switch_Outlet  attribute  of  switch,  there,  the  ":2"  indicates  that  each  switch  has  exactly  two  pipes 
serving  as  its  Switch_Outlet  attribute  end  comment 

always  prohibited  MORE  THAN  ONE  SOURCE 
exists  source.  7  source. 2; 

Gist  comment  constraints  may  be  stated  as  predicates  following  either  always  required  (in  which  case  the 
predicate  must  always  evaluate  to  truel  or  always  prchib.ted  (m  which  case  the  predicate  must  never  evaluate  tc 
true.  The  usual  logical  connectives  Quantification  etc  .  may  be  used  in  Gist  predicates  Distinct  sutt.xes  on 
type  names  after  exists  have  the  special  meaning  of  denoting  distinct  ob/ects  en£  comment 

always  required  PIPE_EMERGES_FROM_UNIQUE_SWITCH_OR_SOURCE 
for  an  pipe  ||  ( countf  a  switch _or_source  |  (switch  union  source)  || 

(pipe  =  switch_cr_source  Switch_Outlet  qt 
pipe  =  swnch._cr_soi.rce  Source_Outlet ) )  =  1  ); 

Gist  comment  •  the  values  of  attributes  can  be  retnevec  in  the  following  manner  if  obi  is  an  obiect  of  type  7. 
where  type  t  has  an  attribute  Att.  then  ob/  Att  Denotes  any  object  serving  as  oof  s  Att  attribute  gno  comment 


relation  IMMEDIATELY_BELOW(/b7  |  location  ib2  |  location) 
definition 
/b  7  =  (  case  ib2  of 

a  pipe  =  >  ib2  :  Pipe_Outlet: 

3  switch  =  >  ;02  :  Switch_Outlet 
the  source  =>  ib2  :  Source_Outlet 
end  case ), 

Gist  comment  ■  the  predicate  ot  a  defined  relation  denotes  those  tuples  of  objects  participating  in  that  relation 
For  any  tuple  of  objects  ct  the  appropriate  types  mat  tuple  (in  the  above  relation  a  2-tupie  of  .ocx'iOns)  is  in  the 
defined  relation  it  and  only  it  tne  defining  predicate  eauais  true  to'  those  obiects  end  comment 


relation  BELOW(b7  |  location,  b2  |  location) 
definition 

IMMEDIATELY_BELOW(b7,b2)Qr 

(  exists  b3  |  location  ||  (  BELOW(07 ,b3)  god  BELOW (b3,b2) ) ); 

always  required  SOURCE  ON  ROUTE  TO  ALL  BINS 
for  a!i  bin  ||  BELOW(b/n,  thg  source); 


Packages-the  objects  moving  through  the  network 

type  package(AI  |  location,  Destination  |  bin)  ; 

always  prohibited  MULTIPLE  PACKAGES  AT  SOURCE 
exists  package.  1 .  package. 2  II  (  package.  7  :  At  *  the  source  and  package. 2  ;  At  *  the  source  ): 
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IMPLEMENTING  SPECIFICATION  FREEDOMS 


Our  Portion 

Spec  comment  •  the  portion  over  which  we  have  control  and  are  to  implement  end  comment 


aaent  package.routero  where 

relation  PACKAGES_EVER_AT_SOURCE(pacfca9es  |  sequence  fif  package) 
definition  packages  =  (g  package  )  ordered  wrt  package  :  At  =  (Jhg  source  ) ; 

The  source  station 

demon  RELEASE  PACKAGE  INTO  .NETWORK  [package,  new] 
triooer  package. new  :  At  =  the  source 
response 
begin 

if  package. new  :  Destination  *■ 

(  a  package. previous  || 

package. previous  immediately  <  package. new 

wrl  PACK  AGES_EVER_AT_SOURCE(‘) ) .  Destination 

Jhgn  WAIT[] ; 

Spec  comment  the  demon  mu',t  delay  release  ol  the  new  package  it  its  destination  differs  from  that  of  the 
previous  package  (the  immediately  preceding  package  to  have  been  at  the  source)  end  comment 

update  :  At  gf  package. new  tg  (the  source) :  Source_Outlet 
gng; 


Gist  comment  -  a  demon  is  a  datatriggered  process  Whenever  a  State  change  takes  place  in  which  the  value 
of  the  demon's  triooer  predicate  changes  from  faise  to  true,  the  demon  is  triggered  and  performs  its  response 
end  comment 


action  WAIT[] ; 

The  switches 

relation  SWITCH  JS.EMPTY (switch) 
definition  not  exists  package  ||  ( package  :  At  =  switch  ) ; 

demon  SET_SWITCH[sw/fch] 
irjgflgr  Random() 
response 
begin 

require  SWITCH_IS_EMPTY(sw/fcb); 

update  :  Switch_Setting  switch  ig  switch  :  Switch.Outlet 

end; 

Spec  comment  the  nondeterminism  of  when  and  which  way  to  set  switches  is  constrained  by  the  always 
prohibited  that  follows  shortly.  gQji  comment 
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relation  PACK AGES_TO_BE_ROUTED_BY_SWITCH(packages  i  sequence  gf  PACKAGE,  switch j 
definition 
packages  = 

(  a  package  ||  {  BELOW  (switch,, package  ;  At)  and 

B£LOW(package  :  Destination. a'vwfcn)  and 

not  PACKAGE_IN_CORRECT_SWITCH_WRONGLY_SET(package) ) 

)  ordered  wrt  PACKAGES  EVER  AT  SOURCEf) ; 


Spec  commeni  •  packages  to  be  routed  by  a  switch  are  those  packages  tor  whom  the  following  conditions  are 
true  (i)  the  switch  lies  below  them,  (ii)  the  switch  lies  on  their  routes  to  their  destinations;  and  (lii)  they  are  not  in 
some  switch  set  the  wrong  way  The  sequence  is  ordered  by  the  order  in  which  the  packages  were  at  the  source 
Note  that  this  excludes  packages  that  are  already  misrouted;  there  may  be  such  packages  on  their  way  to  this 
switch,  but  since  they  are  already  misrouted  the  switch  will  not  have  to  route  them  in  any  particular  direction 
end  comment 

relation  PACKAGE  IN  CORRECT  SWITCH  WRONGLY  SET(oackaoe) 
definition 

exists  switch  ||  ( package  :  At  =  switch  and 

BELOW(package  :  Destination  .switch)  and 

not  BELOW(package  :  Destination, switch  ;  Switch_Setting) ) ; 

Spec  comment  •  a  package  is  in  a  correct  switch  that  is  wrongly  set  it  the  switch  lies  on  the  route  to  that 
package  s  destination  but  the  switch  is  currently  set  the  wrong  way.  (This  is  how  a  package  becomes  misrouted.) 
end  comment 

always  prohibited  DID_NOT_SET_SWITCH_WHEN_HAD_CHANCE 
exists  package,  switch  || 

(  PACKAGE_IN_CORRECT_SWITCH_WRONGLY_SET (package) 
and 

( ( SWITCH_IS_EMPTY(sw/fcf7)  and 

package  =  firsttPACKAGES  TO  BE  ROUTED  BY  SWITCHC.sw/fch) )  )asof  true  ) 

); 


Spec  comment  •  there  must  never  be  a  state  in  which  a  package  is  in  a  wrongly  set  switch  if  there  has  been  an 
opportunity  to  set  the  switch  correctly  for  that  package,  i.e  .  at  some  time  that  package  was  the  tirst  of  those  due 
to  be  routed  by  the  switch  and  the  switch  was  empty  eng  comment 


Indicating  the  arrival  of  a  misrouted  package  in  a  bin 

demon  DETECT_MlSROUTED_ARRIVAL[package.m/sroufed,  bin. reached,  bin. intended] 
trigger  package. misrouted  :  At  =  bin. reached  and 

package. misrouted  :  Destination  =  bin.intended 
response  DISPLAY_MISROUTING[  bin. reached,  bin.intended  J ; 

action  DISPLAY_MISROUTING[  bin. reached,  bin.intended  ]; 
end 
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The  Environment 


agent  environment!)  where 


Arrival  of  packages  at  the  source 

demon  CREAT£_PACKAGE[] 
trigger  Random() 
response 

create  package. new  ||  (  package. new  :  Destination  =  a  bin  and 
package. new  :  At  =  thg  source  )  ; 


Spec  comment  •  for  the  purposes  of  defining  the  environment  in  which  the  package  router  is  to  operate, 
packages  with  some  random  bin  as  their  destination  appear  at  random  intervals  at  the  source  (subject  to  the 
prohibition  on  there  being  multiple  packages  at  the  source)  end  comment 


Movement  of  packages  through  the  network 

relation  CONNECTED_TO(/oca//on.  7,  location. 2) 
definition 

location. 2  =  (  case  location.  7  of 

3  pipe  =  >  location.  7 :  Pipe_Outlet: 

§  switch  =  >  location.  7  :  Switch_Setting 
end  case ): 


demon  MOVE_PACKAGE[pacfcage,  location. next] 
trigger  Random() 
response 

if  CONNECTED_TO(pacfcage  :  At,  location. next) 
then  update  :  At  Qf  package  Jq  location. next', 


Spec  comment  -  modelling  the  unpredictable  movement  of  packages  through  the  network  is  achieved  by 
having  this  demon  at  random  move  a  random  package  from  one  location  to  the  next  CONNECTED_TO  location 
end  comment 


always  prohibited  MULTIPLE  PACK  AGES  REACH  LOCATION_SIMlJLTANFOHSl  Y 
gxjsts  package.  7,  package. 2 ,  location 

II  ( ( start  package.  1  :  At  =  location  )  and  (  start  package. 2  :  At  =  location  ) ) ; 

Gist  comment  •  start  <predicate>  is  true  if  the  predicate  has  just  changed  in  value  from  false  to  true  end 
comment 

Spec  comment  ■  the  mechanical  construction  of  the  router  is  such  that,  although  packages  may  bunch  up,  the 
passage  of  each  individual  package  may  be  detected  This  we  model  by  constraining  the  granularity"  of 
movement  to  be  that  of  individual  packages  gnjj  comment 
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ilwavs  prohibited  PACK  AGES_LEAVE_OUTJDF_ORDER 
exists  package.  1 ,  package. 2.  common jocation  |  location 
II  ( (  start  package.  7  :  At  =  common  Jocation  < 
start  p  ackaae.2  :  At  *  common  Jocation  )  an£f 
package.  7  :  At  =  common  Jocation  and 
nfit  package. 2  :  At  =  common  Jocation  ); 

Spec  comment  -  it  is  prohibited  that  package  1  enter  before  package. 2  yet  still  be  theie  when  packaged  has 
left  end  comment 

Abstraction  Specification 


Gist  comment  •  the  behaviors  denoted  by  the  specification  are  an  abstraction  of  the  detailed  behaviors  of  the 
preceding  system  This  section  states  just  which  of  those  details  are  to  be  included  in  the  abstracted  behaviors 
end  comment 


tvoes 

LOCATION,  SOURCE,  PIPE,  SWITCH,  BIN,  PACKAGE; 


attributes 

Source_Outlet.  Pipe_Outlet,  Switch_Outlet,  Switch_Setting, 
At,  Destination  ; 


aslians 

DISPLA Y_MISROUTING,  WAIT 
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Implementation  Specification 

Gist  comment  •  this  section  states  what  the  portion  to  be  implemented  may  observe  and  what  it  may  effect. 
end  comment 

implement  package_router 
observing 
types 

LOCATION,  SOURCE.  PIPE,  SWITCH,  BIN,  PACKAGE  ; 

attributes 

Source_Outlet,  Pipe_Outlet,  Switch_Outlet,  Switch_Setting 
predicates 

Start  (  a  package  ) :  At  =  thg  source, 
start  ( a  package  ) :  At  =  switch, 
finish  (  a  package  ) :  At  =  switch. 
start  (  a  package  )  :  At  =  bin  ; 

exists  package  |j  ( package  :  Destination  =  bin  and  package  :  At  =  thg  source  )  . 

Spec  comment  -  the  router  is  limited  to  observing  the  routing  network,  the  arrival  of  packages  at  the  source 
and  their  movement  into  and  out  of  switches  and  into  bins,  and  the  destination  of  a  package  while  it  is  located  at 
the  source  end  comment 

effecting 

attributes 

switch  :  Switch_Setting, 

package  :  At  asof  package  :  At  =  thg  source  ; 

Spec  comment  -  the  router  is  limited  to  effecting  the  setting  of  switches  and  the  release  of  packages  at  the 
source  end  comment 
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